Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to TR-106.
Nothing was collected or created yet.
TR-106
View on Wikipediafrom Wikipedia
 | |
| Country of origin | United States |
|---|---|
| Manufacturer | TRW |
| Application | low-cost throttleable booster engine |
| Liquid-fuel engine | |
| Propellant | Liquid oxygen / LH2 (liquid hydrogen) |
| Performance | |
| Thrust, sea-level | 2,892 kN (650,000 lbf) |
The TR-106 or low-cost pintle engine (LCPE) was a developmental rocket engine designed by TRW under the Space Launch Initiative to reduce the cost of launch services and space flight. Operating on LOX/LH2 the engine had a thrust of 2892 kN, or 650,000 pounds, making it one of the most powerful engines ever constructed.[1]
Overview
[edit]The goal of the development was to produce a large, low-cost, easy-to-manufacture booster engine. The design used a single element coaxial pintle injector, a robust type of injector. It also used ablative cooling of the combustion chamber and nozzle instead of the more costly to manufacture regenerative cooling.[1]
The use of the pintle injector allows the engine thrust to be widely throttleable, as was the case for the lunar module descent engine.[1]
Status
[edit]Tom Mueller was a lead engineer for development of the LCPE,[2][3] a 650,000 lbf thrust LOX/LH2 engine. In the summer of 2000, this LCPE was successfully hot fire tested at 100 percent of its rated thrust as well as at a 65 percent throttle condition at NASA's John C. Stennis Space Center in Mississippi.[4] TRW changed the pintle injector configuration three times during testing to explore the engine's performance envelope; engineers also replaced the ablative chamber once while the engine was on the test stand—demonstrating the LCPE's ease of operation. Test results demonstrated that the engine was stable over a wide variety of thrust levels and propellant ratios.[1]
Development of the engine was temporarily discontinued with the cancellation of the Space Launch Initiative.[1] In 2002 TRW was acquired by Northrop Grumman and development of a LOX/RP-1 engine (TR-107) continued, under contract to NASA, for potential use on next-generation launch and space transportation vehicles.[5]
Legacy
[edit]Tom Mueller became TRW vice president of propulsion. In 2002, Elon Musk asked Mueller to join him as a founding member of SpaceX.
Technology lessons from the Low Cost Pintle Engine project were used in the development of the SpaceX Merlin engine.[6][7] Mueller joined SpaceX in 2002, becoming its head of propulsion, along with other TRW staffers.[8] The turbopump, meanwhile, was contracted to Barber-Nichols, Inc., which derived their pump from their work on the FASTRAC turbopump.[9] After SpaceX accused Northrop Grumman, TRW's parent, of letting engineers supervising SpaceX under a Pentagon contract use that information on Northrop's own rocket technology, Northrop Grumman then sued for theft of trade secrets.[10][11] The dueling suits were settled in early 2005.[12]
See also
[edit]References
[edit]- ^ a b c d e "TR-106". Astronautix.com. 2000-09-26. Archived from the original on August 20, 2016. Retrieved 2020-07-06.
- ^ "Company". SpaceX. 2010-12-08. Archived from the original on 2013-01-12. Retrieved 2021-06-04.
- ^ Mueller, Tom; Dressler, Gordon. TRW 40 klbf LOX/RP-1 low cost pintle engine test results. 35th AIAA/ASME/SAE/ASEE Joint Propulsion Conference and Exhibit, Huntsville, Alabama, July 24, 2000
- ^ "Stennis Space Center". Spinoff.nasa.gov. 2011-05-01. Archived from the original on 2013-03-01. Retrieved 2014-02-17.
- ^ "Booster Vehicle Engines". Archived from the original on May 23, 2010.
- ^ Seedhouse, Eric. SpaceX: Making Commercial Spaceflight a Reality, Springer Science & Business, Jun 15, 2013, p. 36
- ^ Air & Space Magazine, December 2011/January 2012, p. 25
- ^ Reingold, Jennifer. Hondas in Space, Fast Company, February 2005
- ^ "Rocket Engine Turbopumps". Barber Nichols. 1999-04-30. Retrieved 2014-02-17.
- ^ Karp, Jonathan; Paztor, Andy. Can Defense Contractors Police Their Rivals Without Conflicts? Wall Street Journal, December 28, 2004
- ^ "Brian Ledahl, Partner - Russ August & Kabat, Los Angeles Intellectual Property Attorney". Raklaw.com. Archived from the original on 2014-02-06. Retrieved 2014-02-17.
- ^ Journal, Jonathan KarpStaff Reporter of The Wall Street (2005-02-11). "Northrop Settles Rocket Dispute With SpaceX". Wall Street Journal. ISSN 0099-9660. Retrieved 2021-06-04.
External links
[edit]
Media related to TR-106 at Wikimedia Commons- TRW Engine Development, 2000, AIAA Archived 2017-08-09 at the Wayback Machine
| Liquid fuel |
|  | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Solid fuel |
| |||||||||||||||||
| ||||||||||||||||||
TR-106
View on Grokipediafrom Grokipedia
Introduction
Purpose and Scope
TR-106, titled "Data Model Template for CWMP Endpoints and USP Agents," is a technical report published by the Broadband Forum that establishes guidelines for developing standardized data models in device management protocols.[5] Its primary goal is to ensure consistency and interoperability in managing customer premises equipment (CPE), such as gateways, routers, and IoT devices, by providing a unified template for data representation across different implementations.[5] This standardization facilitates remote management tasks, including configuration, diagnostics, and firmware updates, by promoting a common structure that reduces integration challenges for service providers and vendors.[6] The scope of TR-106 encompasses normative rules for the overall data hierarchy, parameter definitions, and schema validation to create robust, extensible data models.[5] It defines the structural requirements, such as a single root "Device." object and a "Services." object for organizing components, along with versioning mechanisms (e.g., major and minor versions like 2.17) to maintain backward compatibility.[5] Additionally, it outlines profile conventions, which are named collections of requirements specifying supported features, and includes XML schemas (DM for data models and DT for device types) to enforce rigorous validation.[5] However, TR-106 deliberately excludes the definition of specific device data models, such as those detailed in TR-181, focusing instead on the foundational template.[5] By applying to all CWMP (TR-069) endpoints and USP (TR-369) agents, TR-106 ensures uniformity in how these protocols handle data models for broadband and user services platforms.[5] This approach supports enhanced flexibility in USP implementations, such as through commands and events, while maintaining compatibility with CWMP's parameter-based operations.[5] Overall, the document prioritizes conceptual frameworks over device-specific details, enabling developers to build interoperable solutions that scale across diverse CPE ecosystems.[6]Relation to CWMP and USP
TR-106 originated as a foundational data model template for devices enabled by the CPE WAN Management Protocol (CWMP), specified in TR-069, where it defines the structural guidelines for SOAP-based management sessions between Auto Configuration Servers (ACS) and Customer Premises Equipment (CPE).[5] This template establishes the Path Name syntax, base data types, and overall hierarchy used in CWMP to ensure consistent representation of device capabilities and configurations during remote management operations. With Amendment 8 in May 2018, TR-106 evolved to support the User Services Platform (USP), defined in TR-369, by incorporating provisions for message-based communication between controllers and agents in disaggregated network architectures.[5] This update enables USP agents to utilize the same data model templates while adapting to Protocol Buffers encoding and asynchronous operations, extending CWMP's foundational elements to modern, multi-tenant, and IoT-oriented deployments.[7] TR-106 plays a critical interoperability role by ensuring that data models, such as the Device:2 baseline in TR-181, remain compatible across both CWMP and USP protocols, thereby supporting hybrid environments where legacy and next-generation management systems coexist. This shared framework allows for seamless migration and unified tooling in device management ecosystems developed under the Broadband Forum.[8] In terms of application differences, CWMP via TR-069 focuses on traditional, bidirectional ACS-to-CPE interactions for broadband device provisioning, whereas USP via TR-369 emphasizes cloud-native, southbound controller-to-agent management with enhanced security features like end-to-end encryption and support for multiple message transfer protocols.[7]History and Development
Initial Release and Early Versions
The TR-106 specification was first released in September 2005 as Issue 1 by the DSL Forum, the predecessor organization to the Broadband Forum. Titled "Data Model Template for TR-069-Enabled Devices," it established a foundational framework for the InternetGatewayDevice root object to support the CPE WAN Management Protocol (CWMP) defined in TR-069. This initial version provided a standardized baseline for managing customer premises equipment (CPE) in broadband networks, ensuring interoperability among TR-069-enabled devices.[9] Developed in response to inconsistencies observed in early CWMP data models for DSL home networks, TR-106 aimed to create a unified structure and set of guidelines for device management. It introduced basic object definitions, such as DeviceInfo and ManagementServer, along with parameter naming conventions using a hierarchical dot notation (e.g., Device.ManagementServer.URL). Additionally, it specified Inform message requirements for device bootstrapping, mandating inclusion of key parameters like DeviceSummary and HardwareVersion to facilitate initial ACS-CPE interactions. These elements prioritized conceptual consistency over device-specific details, allowing for extensible vendor augmentations while maintaining a common core.[9] In November 2006, Issue 1 Amendment 1 was published, expanding the specification with support for UDP-based connection requests via STUN parameters under the ManagementServer object, such as STUNEnable and STUNServerAddress. This amendment also incorporated normative references to XML-related standards, including SOAP 1.1 for data types and RFC 3986 for URI formats, enhancing the precision of parameter definitions. Around 2008, following the DSL Forum's rebranding to the Broadband Forum, TR-106 underwent further renaming and expansion to align with broader broadband management needs, while retaining its core focus on CWMP data modeling.[10][11]Amendments and Key Evolutions
The development of TR-106 has progressed through 16 amendments since its initial 2005 release, with iterative updates addressing technical refinements, schema enhancements, and evolving management protocol needs. Amendment 2, released in November 2008, introduced the data model definition XML Schema and normative XML definitions for common objects and components, correcting early errata and standardizing template structures.[12] Subsequent amendments built on this foundation to support broadband advancements. Amendment 3 in September 2009 added the device type XML Schema, enabling more precise device categorization. Amendment 4 in February 2010 shifted core data model definitions to TR-181 Issue 1, streamlining TR-106's focus on templates. Amendment 5 in November 2010 replaced inline named data type definitions, such as IPAddress, with references to normative XML schemas, improving modularity and reducing redundancy.[13][12] Key evolutions reflect adaptations to emerging technologies like IoT proliferation and cloud-based management while maintaining backward compatibility. Amendment 6 in July 2011 removed proxying and common object definitions, incorporating alias parameter requirements for efficient instance management. Amendment 7 in September 2013 introduced new feature descriptions for data model and device type schemas, along with an annex outlining Broadband Forum data model requirements; a 2014 update supported file-based schema distribution without altering the document. Amendment 8 in May 2018 marked a significant shift by adding support for User Services Platform (USP) through mountable objects, removing obsolete references, and relocating device requirements to TR-069, facilitating hybrid CWMP-USP deployments.[12] Later amendments emphasized schema precision and USP integration. Amendment 9 in September 2019 and Amendment 15 in April 2025 involved no substantive document changes, focusing instead on schema maintenance. Amendment 10 in November 2020 converted the specification to Markdown format with editorial clarifications for better accessibility. Amendment 11 in January 2022 enhanced schema rules by clarifying USP features like the forceEnabled attribute, introducing new description templates, and adding a secured attribute for access control. Amendment 12 in June 2023 refined mountable object rules, path scoping, and attribute definitions, while incorporating a new Data Model Registry (DMR) Schema section. Amendment 13 in January 2024 specified vendor-specific prefix requirements to avoid naming conflicts. Amendment 14 in July 2024 provided guidance on access types, introduced attributes like dmr:noNameCheck, and documented Markdown syntax for templates. The latest Amendment 16, issued in November 2025, involved no substantive document changes, focusing instead on schema maintenance.[14][15] These amendments, driven by the need to accommodate broadband evolution—including IoT device growth, cloud orchestration, and protocol interoperability—have cumulatively ensured TR-106's longevity. Over 16 iterations, the specification has remained a cornerstone for device data modeling, with version history tracked via official release tables on the Broadband Forum's data model template site, allowing implementers to reference precise URNs like "urn:broadband-forum-org:tr-106-1-16" for compliance.[12]Technical Architecture
Data Hierarchy and Structure
The TR-106 data model employs a hierarchical tree structure to organize device information, with a single root object named "Device." serving as the top-level container for all elements.[5] This root branches into sub-objects, parameters, and instances, enabling a logical representation of device capabilities, configurations, and status. For example, the path "Device.Info.Manufacturer" uses dot notation to navigate from the root to a specific parameter, where "Device." denotes the root, "Info" an intermediate object, and "Manufacturer" a leaf parameter holding a string value.[5] The notation is case-sensitive and prohibits hyphens in names, ensuring unambiguous parsing across CWMP and USP protocols.[5] To support scalability in diverse device deployments, TR-106 mandates multi-instance objects (MIOs), which allow multiple occurrences of the same object type, such as network interfaces or service instances.[5] Each MIO requires a "NumberOfEntries" parameter at the parent level to indicate the current instance count, facilitating dynamic addition or removal.[5] Parameters within this hierarchy are classified as writable (read-write access for configuration, e.g., enabling a feature) or read-only (for reporting status, e.g., uptime statistics), promoting secure management while minimizing unauthorized changes.[5] Objects themselves may contain commands for actions and events for notifications, further enriching the structure without altering its tree-like form. Path syntax in TR-106 ensures precise referencing: absolute paths begin with "Device." for global uniqueness (e.g., "Device.Services.LANDevice.1."), while relative paths omit the root and start from a mount point or current object (e.g., ".Stats." from within a device stats object).[5] Aliasing enhances dynamic addressing by assigning a writable string alias to instances (e.g., "Device.Services.ABCService.Alias1."), allowing stable references even as numerical identifiers change during operations like instance creation.[5] These paths support operations in protocols like CWMP and USP, where aliases prevent breakage in management sessions. Structural constraints maintain integrity: the hierarchy forbids cycles to prevent infinite loops in traversal, and objects are designated as mandatory (required for compliance) or optional (implementation-dependent) to balance standardization with flexibility.[5] Event-based notifications tie into this framework by allowing parameters to signal changes, such as through active notification flags mandated in certain profiles, enabling real-time updates without constant polling.[5] Versioning extends this hierarchy by annotating elements with version indicators, but the core structure remains static across amendments.[5]Versioning and Profile Mechanisms
TR-106 employs a structured versioning system to manage the evolution of its data model, ensuring stability and interoperability across implementations. The model uses baseline versions, such as Device:2.0, which establish the foundational structure, while subsequent amendments, like 2.17 or 2.18, introduce compatible additions to objects and parameters without altering existing ones.[16] Major version increments signal potentially incompatible changes, whereas minor increments and amendments focus on backward-compatible enhancements.[16] Deprecation notices are applied to obsolete parameters and objects, marking them for potential removal in the next major version while requiring them to remain fully functional in interim releases.[16] This approach builds upon the data hierarchy as the core organizational framework for tracking these evolutions.[16] To address diverse implementation needs, TR-106 incorporates a profile system that defines optional subsets of the data model tailored to specific use cases. Profiles, such as the Baseline profile, specify required objects and parameters, while specialized ones like BasicManagement outline mandatory elements for scenarios including VoIP or Wi-Fi management.[16] These profiles enable device manufacturers and service providers to implement focused subsets without adopting the full model, promoting compliance and efficiency.[16] Key mechanisms facilitate negotiation and compatibility between the Auto Configuration Server (ACS) or Controller and the Agent. Version indicators are included in Inform messages to communicate the supported data model version, allowing the ACS to adapt its interactions accordingly.[16] Profile aliases serve as identifiers for these subsets, enabling dynamic negotiation during session establishment to align on supported capabilities.[16] Backward compatibility is enforced by requiring new versions to fully support prior baselines as supersets, ensuring seamless operation with legacy devices.[16] Additionally, diff reports generated via the Data Model Report (DMR) schema detail changes, such as added or removed objects, between versions to aid developers in migration.[16]Data Model Components
Objects, Parameters, and Notation
In the TR-106 data model, objects serve as containers for related parameters and sub-objects, forming the hierarchical structure of device management information.[16] These internal nodes can be single-instance, such as read-only containers likeDevice.DeviceInfo., or multi-instance tables, such as Device.LAN.Interface.{i}., where {i} denotes a placeholder for unique instance identifiers starting from 1 or using aliases.[16] Multi-instance objects include a NumberOfEntries parameter to indicate the current count of instances, enabling dynamic management of collections like network interfaces.[16]
Parameters represent the leaf nodes in this hierarchy, storing actual configuration values, status information, or operational data as name-value pairs.[16] For example, Device.DeviceInfo.ModelName is a read-only string parameter providing the device's model identifier, while writable parameters like Device.LAN.Interface.1.MaxBitRate allow modification of settings such as bandwidth limits.[16] Parameters are classified by access type, including read-only for status metrics (e.g., packet counts), read-write for configurable options, and write-once-read-only for initial setup values; hidden parameters may be defined via status attributes to restrict visibility in certain contexts.[16] Full path names for parameters are case-sensitive, limited to 256 characters, and constructed by appending the parameter name to the parent's path using dots (e.g., Device.Services.FTP.Server.1.Port).[16]
Notation in TR-106 employs standardized conventions and macros to define and reference data model elements clearly in templates and documentation.[16] Object references use {{object}} to denote container paths, such as in descriptions like "This parameter belongs to the {{object}} instance"; enumerated values are indicated with {{enum}}, listing options like {{enum|Enabled|Disabled}}; and external links or references to other elements use {{reference}}, for example, {{reference|Device.LAN.Interface.{i}.}}.[16] Fault management for invalid operations, such as setting undefined parameters, relies on standardized codes from associated protocols like CWMP, ensuring interoperability.[16] Naming requirements mandate that object and parameter names begin with an uppercase letter, followed by alphanumeric characters only, avoiding spaces, periods, hyphens, or underscores (underscores are allowed only for internal vendor-specific names starting with an underscore); Broadband Forum conventions specify that objects start with uppercase letters, while parameters use camelCase for readability.[16] Descriptions are mandatory for all elements, providing semantic clarity and usage notes in a structured template format to support developers and implementers. As of Amendment 16 (November 2025), the core structures remain consistent with prior versions.[16]
Data Types and Access Specifications
The TR-106 data model defines a set of base data types derived from a subset of SOAP primitives to ensure interoperability in CWMP and USP environments. These include string, which supports variable lengths constrained by facets such as maxLength (commonly up to 64 characters for parameters like aliases), unsignedInt ranging from 0 to 4294967295 (2^32 - 1), boolean accepting true/false or 1/0 values, dateTime in ISO 8601 UTC format (e.g., 2008-04-07T14:22:01Z), and base64 for encoding binary data with optional length constraints.[16][17] Extended base types like unsignedLong accommodate larger counters, spanning 0 to 2^64 - 1, while hexBinary handles hexadecimal representations.[16] Derived types build on these bases with specific formats and constraints for common network elements. For instance, IPAddress is a string type limited to 45 characters, supporting both IPv4 dotted-decimal notation (e.g., 192.168.1.1) and IPv6 hexadecimal format (e.g., 1080::8:800:200C:417A), with an empty string indicating an unspecified address.[17] Similarly, MACAddress is a string constrained to 17 characters in colon-separated hexadecimal format (e.g., 00:1A:2B:3C:4D:5E), also defaulting to an empty string when unspecified.[17] Aliases for these types, such as NetworkAddress or HostName, provide shorthand notations while inheriting the underlying constraints.[16] Access specifications govern parameter interactions, with ReadWrite allowing both retrieval and modification, ReadOnly permitting reads only (e.g., for status indicators), and writeOnceReadOnly for parameters writable once then read-only (e.g., for initial setup).[16] Notification attributes further control change reporting: passive notifications occur on value updates without active polling, while active notifications can be configured as normal (on change), forceEnabled (always sent), or forceDefaultEnabled (with denial option), often tied to events like diagnostics completion.[16] Constraints enhance type precision, including ranges (e.g., minInclusive and maxInclusive for numeric types), enumeration lists for restricted strings, and pattern matching via regular expressions.[16] Units are standardized using powers of 2—such as bytes (1), kilobytes (1024), or seconds—to denote scale for counters and measurements.[16] Default values are specified per parameter, with factory defaults marked as mandatory (e.g., via {{factory}} notation), implementation-defined options as recommended ({{impldef}}), and null representations like empty strings for base64/string, 0 for unsignedInt, false for boolean, or a zero epoch for dateTime.[16]Implementation and Standards Integration
XML Schemas and Templates
The XML schemas and templates in TR-106 provide a standardized framework for defining, extending, and validating data models used in CWMP (CPE WAN Management Protocol) endpoints and USP (User Services Platform) agents, ensuring consistency and interoperability across device management systems.[16] These tools, introduced in early amendments and refined over subsequent versions, enable the creation of machine-readable XML documents that describe hierarchical data structures, while templates facilitate human-readable representations.[16] The DM (Data Model) Schema, defined in Annex A of TR-106, serves as the core normative XML structure for instantiating data models, such as those in files namedmodel_*.xml (e.g., tr-181-2-11-0.xml).[16] It specifies elements like <dataType>, <model>, <object>, and <parameter>, with attributes including name, base, status, and version indicators (e.g., "1.0" or "1.2.3") to define objects, parameters, and their relationships.[16] Objects can be single-instance or multi-instance (tables) with unique keys, forming a hierarchy starting from root elements like "Device." and services under "Device.Services.", while facets such as size, pathRef, range, enumeration, pattern, and units enforce data constraints.[16] This schema embodies guidelines for UTF-8 encoding, unique parameter naming, and versioned definitions to minimize implementation ambiguities.[16]
The DT (Device Type) Schema, outlined in Annex B, extends the DM Schema by defining device-specific data types and custom extensions, such as named types derived from SOAP primitives (e.g., IPAddress or MacAddress).[16] It uses an <import> element with a file attribute (conforming to RFC 3986 for URLs) to reference DM instances without redefining root or service objects, allowing vendors to specify supported features and custom types for integration with controllers.[16] Compliance requires adherence to XML Schema norms, including restrictions on data type ranges like string(Min:Max) or decimal(Min:Max step Step).[16]
Templates in TR-106 incorporate markup for generating readable documentation from XML definitions, particularly in HTML reports that enhance model comprehension.[16] Common markup includes {{biblio}} for bibliographic references (e.g., linking to standards like TR-069), {{object}} for hierarchical object representations, {{param}} for parameter details (e.g., {{param|Enable}}), {{reference}} for path references, and {{enum}} for enumeration values.[16] These are processed by validation tools to expand into structured text, supporting reports with sections like data types, references, and profile definitions.[16]
Validation within these schemas enforces normative rules for compliance, including checks for data type restrictions, path scoping, enumeration validity, pattern matching, and reference integrity.[16] The DMR (Data Model Report) Schema, a non-normative extension available at https://www.broadband-forum.org/cwmp-datamodel-report-schema, generates customizable reports from XML instances, such as full model overviews or diffs highlighting changes between versions (e.g., via attributes like dmr:hideDeleted).[16] These reports, often in HTML format (e.g., tr-181-2-11-0.html for complete details or tr-181-2-11-0-diffs.html for amendments), include summaries, tables of contents, and hierarchical views to aid developers and integrators.[16] The schemas and support files, including common bibliographic references and data types, are hosted in the TR-106 GitHub repository for collaborative maintenance.[16]