Appendices

• Appendix I: Example RG Queuing Architecture
• Appendix II: Use of Bridging Objects for VLAN Tagging
  • II.1 Tagged LAN to Tagged WAN Traffic (VLAN Bridging)
  • II.2 Tagged LAN to Tagged WAN Traffic (Special Case with VLAN ID Translation)
  • II.3 Untagged LAN to Tagged WAN Traffic
  • II.4 Internally Generated to Tagged WAN Traffic
  • II.5 Other Issues
    • II.5.1 More than one Downstream Interface in a Bridge
    • II.5.2 802.1D (Re)-marking
    • II.5.3 More than one VLAN ID Tag Admitted on the Same Downstream Interface
• Appendix III: Wi-Fi Theory of Operation
  • III.1 Multi-radio and Multi-band Wi-Fi Radio Devices
  • III.2 Definitions
  • III.3 Number of Instances of WiFi.Radio Object
  • III.4 SupportedFrequencyBands and OperatingFrequencyBand
  • III.5 Behavior of Dual-band Radios when OperatingFrequencyBand Changed
  • III.6 SupportedStandards and OperatingStandards
  • III.7 Different Types of WiFi Errors
  • III.8 Wi-Fi Data Elements
  • III.9 Incorporating Wi-Fi Data Elements into TR-181
    • III.9.1 Data Sources for Wi-Fi Data Elements
    • III.9.2 Mapping new Wi-Fi Data Elements objects and parameters
  • III.10 Wi-Fi Sensing Service
    • III.10.1 Exchange Management
    • III.10.2 Sensing Measurement Delivery
• Appendix IV: Use Cases
  • IV.1 Create a WAN Connection
  • IV.2 Modify a WAN Connection
  • IV.3 Delete a WAN Connection
  • IV.4 Discover whether the Device is a Gateway
  • IV.5 Provide Extended Home Networking Topology View
  • IV.6 Determine Current Interfaces Configuration
  • IV.7 Create a WLAN Connection
  • IV.8 Delete a WLAN Connection
  • IV.9 Configure a DHCP Client and Server
    • IV.9.1 DHCP Client Configuration (ACME devices)
    • IV.9.2 DHCP Server Configuration (gateway)
  • IV.10 Reconfigure an Existing Interface
  • IV.11 Backup / Restore Using Vendor Configuration Files
• Appendix V: IPv6 Data Modeling Theory of Operation
  • V.1 IPv6 Overview
  • V.2 Data Model Overview
  • V.3 Enabling IPv6
  • V.4 Configuring Upstream IP Interfaces
    • V.4.1 Configuration Messages Sent Out the Upstream IP Interface
    • V.4.2 IPv6 Prefixes
    • V.4.3 IPv6 Addresses
  • V.5 Configuring Downstream IP Interfaces
    • V.5.1 IPv6 Prefixes
    • V.5.2 IPv6 Addresses
  • V.6 Device Interactions
    • V.6.1 Active Configuration
    • V.6.2 Monitoring
  • V.7 Configuring IPv6 Routing and Forwarding
• Appendix VI: 6rd Theory of Operation
  • VI.1 RFC 5969 Configuration Parameters
  • VI.2 Internal Configuration Parameters
  • VI.3 IPv4 Address Source
  • VI.4 Sending All Traffic to the Border Relay Server
  • VI.5 Internal Treatment of IPv6 Packets
• Appendix VII: Dual-Stack Lite Theory of Operation
  • VII.1 Internal Treatment of IPv4 Packets
• Appendix VIII: Advanced Firewall Example Configuration
  • VIII.1 Config level
  • VIII.2 Firewall policy
    • VIII.2.1 Policy Level
    • VIII.2.2 Policy referencing
    • VIII.2.3 Policy
    • VIII.2.4 Remarks
  • VIII.3 PriorityMap
  • VIII.4 DMZ example
    • VIII.4.1 Priority and Firewall.DMZ
  • VIII.5 Pinhole example
    • VIII.5.1 Priority and Firewall.Pinhole
  • VIII.6 Service example
    • VIII.6.1 Priority and Firewall.Service
  • VIII.7 PortMapping example
    • VIII.7.1 Controller priority example
    • VIII.7.2 Priority and NAT.PortMapping wildcard precedence
  • VIII.8 PortTrigger example
    • VIII.8.1 Priority and NAT.PortTrigger
  • VIII.9 Firewall logging
    • VIII.9.1 Logging control in firewall rules
    • VIII.9.2 Enabling firewall logging
    • VIII.9.3 Log filtering
    • VIII.9.4 Policy Filtering
    • VIII.9.5 Interface Filtering
    • VIII.9.6 Multiple log table reference
• Appendix IX: IPsec Theory of Operation
  • IX.1 IPsec
  • IX.2 IPsec.Filter
  • IX.3 IPsec.Profile
  • IX.4 IPsec.Tunnel
  • IX.5 IPsec.IKEv2SA
  • IX.6 IPsec.IKEv2SA.ChildSA
• Appendix X: ETSI M2M Remote Entity Management Theory of Operation
  • X.1 ETSI M2M Area Networks
  • X.2 Device:2 Data Model and Functionality for ETSI M2M REM
    • X.2.1 TR-069 Functionality for ETSI M2M REM
  • X.3 Device:2 Data Model and Functionality for ETSI M2M REM
    • X.3.1 M2M Service SCL Execution Environment
    • X.3.2 ETSIM2M Object
• Appendix XI: Provider Bridge Theory of Operation
  • XI.1 Residential Domain Scenario
  • XI.2 Device Traffic Scenario
  • XI.3 Public and Roaming Domain Scenarios
  • XI.4 Provisioning Provider Bridges
    • XI.4.1 Associating Customer Edge Ports with Customer Network Ports
• Appendix XII: ZigBee Theory of Operation
  • XII.1 CWMP management using the ZigBee data model
  • XII.2 CWMP proxying mechanisms and the ZigBee data model
• Appendix XIII: Port Control Protocol Theory of Operation
  • XIII.1 Configuration and monitoring of the PCP Server
  • XIII.2 Monitoring and setting rules set by the PCP client
  • XIII.3 Rapid recovery
• Appendix XIV: GRE Tunnel Theory of Operation
  • XIV.1 L2 Payload over GRE
  • XIV.2 L3 Payload over GRE
• Appendix XV: MAP Theory of Operation
  • XV.1 MAP Configuration Parameters
  • XV.2 Internal Treatment of IPv4 Packets
• Appendix XVI: G.fast Theory of Operation
• Appendix XVII: USB Host Theory of Operation
  • XVII.1 Overview
• Appendix XVIII: Location Management
  • XVIII.1 Overview
  • XVIII.2 Multiple Instances of Location Data
  • XVIII.3 CWMP, USP, Manual, GPS, and AGPS Configured Location
    • XVIII.3.1 Example: Manual, GPS, AGPS, and External:CWMP <rootObject>.Location.{i}.DataObject. Format
    • XVIII.3.2 RFC 5491 and RFC 5139 Location Element Definitions
    • XVIII.3.3 Use of RFC 5491 and RFC 5139 Location XML Elements in CWMP or USP
• Appendix XIX: Fault Management
  • XIX.1 Overview
• Appendix XX: BASAPM and LMAP Theory of Operation
  • XX.1 TR-069 Family of Specifications in the Context of TR-304
    • XX.1.1 TR-304 and IETF LMAP Frameworks
    • XX.1.2 CWMP for Pre-configuration
    • XX.1.3 CWMP for Control and Pre-configuration, IPDR for Reporting
    • XX.1.4 CWMP as a Proxier, IPDR for Reporting
    • XX.1.5 Multi-ACS Deployment
  • XX.2 Derivation of Data Model Elements
    • XX.2.1 Device.BASAPM
    • XX.2.2 Device.LMAP.MeasurementAgent
  • XX.3 Bulk Data Collection in the Context of LMAP
  • XX.4 TR-143 Diagnostics in LMAP
• Appendix XXI: 5G Theory of Operation
  • XXI.1 Overview
  • XXI.2 Architecture
    • XXI.2.1 Network Functions
  • XXI.3 Concepts
    • XXI.3.1 Control User Plane Separation (CUPS)
    • XXI.3.2 Policy
    • XXI.3.3 Multiple PDU sessions
    • XXI.3.4 5G QoS
    • XXI.3.5 Data Network Name (DNN)
    • XXI.3.6 Multiple Access Networks
    • XXI.3.7 Network Slicing
  • XXI.4 Data Model Elements
    • XXI.4.1 Interface Stack
    • XXI.4.2 Data Model
    • XXI.4.3 Examples
• Appendix XXII: Data Elements Theory of Operations
• Appendix XXIII: Logical Interfaces Theory of Operations
  • XXIII.1 Introduction
  • XXIII.2 Concept
  • XXIII.3 WAN mode changes
  • XXIII.4 How to use
  • XXIII.5 Examples
    • XXIII.5.1 Tagged - untagged Ethernet switching
    • XXIII.5.2 IPv4 and IPv6 on a different network interface
• Appendix XXIV: MTU configuration Theory of Operations
  • XXIV.1 Introduction - Understanding MTU in Layer 2 and Layer 3 Networks
  • XXIV.2 Use cases
  • XXIV.3 Interface example
  • XXIV.4 Simple Linux bridge example
• Appendix XXV: 3GPP NAS Theory of Operation
  • XXV.1 Overview
  • XXV.2 Concepts
    • XXV.2.1 3GPP Generations - 2, 3, 4 and 5G
    • XXV.2.2 Control User Plane Separation (CUPS) - 4G and 5G
    • XXV.2.3 Multiple Sessions - 3, 4 and 5G
    • XXV.2.4 Quality of Service (QoS) - 3G, 4G and 5G
    • XXV.2.5 Multiple Access Networks -5G
    • XXV.2.6 Network Slicing - 5G
  • XXV.3 Data Model elements
    • XXV.3.1 Data Model
    • XXV.3.2 Interface Stack - 3G, 4G and 5G
    • XXV.3.3 Examples
• Appendix XXVI: LogRotate Theory of Operation
  • XXVI.1 Introduction
  • XXVI.2 How it works
  • XXVI.3 Examples
    • XXVI.3.1 Example 1: Basic Log Rotation
    • XXVI.3.2 Example 2: Time-based Log Rotation
    • XXVI.3.3 Example 3: Log Rotation with Retention
    • XXVI.3.4 Example 4: Advanced Log Rotation
• Appendix XXVII: MQTT Theory of Operation
  • XXVII.1 Definitions
  • XXVII.2 Securing Connections with TLS
  • XXVII.3 MQTT Client Operation
  • XXVII.4 MQTT broker operation
    • XXVII.4.1 Authentication
    • XXVII.4.2 Access Control
    • XXVII.4.3 MQTT Listeners
    • XXVII.4.4 Broker Process Management
    • XXVII.4.5 End-to-End Broker Configuration Example
  • XXVII.5 MQTT bridge operation
• Appendix XXVIII: Device Certificates
  • XXVIII.1 Introduction
  • XXVIII.2 Secure Storage of Cryptographic Assets
    • XXVIII.2.1 Non-Encrypted Storage
    • XXVIII.2.2 Encrypted Storage
    • XXVIII.2.3 Secure Cryptographic Storage
  • XXVIII.3 Certificate Management
  • XXVIII.4 Certificate Signing Requests (CSRs)
    • XXVIII.4.1 What is a CSR?
    • XXVIII.4.2 Procedure
  • XXVIII.5 Advanced Certificate Management
    • XXVIII.5.1 Creating a Certificate Signing Request (CSR)
    • XXVIII.5.2 Adding a New Certificate
    • XXVIII.5.3 Deleting a Certificate
  • XXVIII.6 Installing Certificate Bundles
  • XXVIII.7 Managing CA Certificate Bundles
    • XXVIII.7.1 Adding CA Bundles
    • XXVIII.7.2 Updating CA Bundles
  • XXVIII.8 Security Fault Codes

Appendix I: Example RG Queuing Architecture

The queuing and scheduling discipline envisioned upstream for the RG is shown in Figure 24, taken from the description of TR-059 [1].

There are multiple access sessions supported in this model, however, all traffic is classified and scheduled in a monolithic system. So, while it might appear at first that the Diffserv queuing and scheduling might apply only to IP-aware access – in fact all access, IP, Ethernet, or PPP is managed by the same system that adheres to the Diffserv model.

For example, at the bottom of the figure, BE treatment is given to the non-IP-aware access sessions (PPPoE started behind the RG or delivered to an L2TP tunnel delivery model). This queue might be repeated several times in order to support fairness among multiple PPPoE accesses – or it can be a monolithic queue with separate rate limiters applied to the various access sessions.

The PTA access is a single block of queues. This is done because NSP access typically works with a single default route to the NSP, and managing more than one simultaneously at the RG would be perilous. The ∑ rate limiter would limit the overall access traffic for a service provider.

Rate limiters are also shown within the EF and AF service classes because the definition of those Diffserv types is based on treating the traffic differently when it falls into various rates.

Finally, at the top of the diagram is the ASP access block of queues. In phase 1A, these queues are provisioned and provide aggregate treatment of traffic mapped to them. In phase 1B, it will become possible to assign AF queues to applications to give them specific treatment instead of aggregate treatment. The EF service class can also require a high degree of coordination among the applications that make use of it so that its maximum value is not exceeded.

Notable in this architecture is that all the outputs of the EF, AF, and BE queues are sent to a scheduler (S) that pulls traffic from them in a strict priority fashion. In this configuration EF traffic is, obviously, given highest precedence and BE is given the lowest. The AF service classes fall in-between.

Note that there is significant interest in being able to provide a service arrangement that would allow general Internet access to have priority over other (bulk rate) services. Such an arrangement would be accomplished by assigning the bulk rate service class to BE and by assigning the default service class (Internet access) as AF with little or no committed information rate.

Given this arrangement, the precedence of traffic shown in the figure is arranged as:

1. EF – red dotted line
2. AF – blue dashed line (with various precedence among AF classes as described in RFC 2597 [26])
3. BE – black solid line

In Figure 24 the following abbreviations apply:

Appendix II: Use of Bridging Objects for VLAN Tagging

In the case of an Ethernet upstream Interface or a VDSL2 upstream Interface based on PTM-EFM, 802.1Q Tagging can be used to tag egress traffic. This choice enables a multi-VLAN architecture in order to deploy a multi-service configuration (high speed Internet, VoIP, Video Phone, IPTV, etc.), where one VLAN or a group of VLANs are associated with each service. If 802.1Q tagging on the upstream interface is used, it is necessary to have a way to associate incoming upstream 802.1Q tagged or untagged traffic or internally generated traffic (PPPoE, IPoE connections) to the egress (and vice-versa). The solution is to apply coherent bridging rules.

Regarding different traffic bridging rules, the possible cases are characterized as follows:

• Tagged LAN to tagged WAN traffic (pure VLAN bridging), with VLAN ID translation as a special case
• Untagged LAN to tagged WAN traffic
• Internally generated to tagged WAN traffic

To better understand the different cases, refer to Figure 25 and to the following examples.

II.1 Tagged LAN to Tagged WAN Traffic (VLAN Bridging)

Ethernet port 1 (instance Device.Ethernet.Interface.2) might be dedicated to VoIP service, receiving VLAN ID x tagged traffic from a VoIP phone, and this port would be included in the same bridge dedicated to VoIP service on the upstream interface (instance Device.Ethernet.Interface.1), identified with the same VLAN ID x.

To achieve this, an interface-based bridge would be created using the Bridging object. A Bridge table entry would be created with entries for Ethernet port 1 and the upstream interface and for the VLAN ID x associated with VoIP.

The Bridging model is depicted in Figure 26, while the configuration rules for this situation are summarized in Table 6.

II.2 Tagged LAN to Tagged WAN Traffic (Special Case with VLAN ID Translation)

Ethernet port 2 (instance Device.Ethernet.Interface.3) might be dedicated to Video Phone service, receiving VLAN ID y tagged traffic from a Video phone, and this port would be included in the same bridge dedicated to Video Phone service on the upstream interface (instance Device.Ethernet.Interface.1), identified by a different VLAN ID (VLAN ID z). In this case a VLAN translation needs to be performed.

To achieve this, a bridge would be created using the Bridging object. A Bridge table entry would be created along with two associated Filter object entries for {Ethernet port 2/VLAN ID z} and {upstream interface/VLAN ID y}. The Filter identifies the ingress interface and causes the ingress frames to be bridged to the egress VLAN, permitting VLAN-ID translation.

The Bridging model is depicted in Figure 27, while the configuration rules for this situation are summarized in Table 7.

II.3 Untagged LAN to Tagged WAN Traffic

Ethernet port 3 (instance Device.Ethernet.Interface.4) might be dedicated to IPTV service, receiving untagged traffic from a STB, and this port would be included in the same bridge dedicated to IPTV service on the upstream interface (instance Device.Ethernet.Interface.1), identified with the VLAN ID k.

To achieve this, an interface-based bridge would be created using the Bridging object. A Bridge table entry would be created, associating in the same bridge untagged frames on Ethernet port 3 with tagged frames on the upstream interface.

The Bridging model is depicted in Figure 28, while the configuration rules for this situation are summarized in Table 8.

II.4 Internally Generated to Tagged WAN Traffic

A device PPPoE internal session (instance Device.PPP.Interface.1) might be dedicated to Management service and this logical interface would encapsulate/de-encapsulate its outgoing or incoming traffic in the VLAN ID j, dedicated to Management service.

To achieve this, instead of using a bridging object, a VLAN Termination interface would be created (Device.Ethernet.VLANTermination.1). The Bridging model is depicted in Figure 29, while the configuration rules for this situation are summarized in Table 9.

II.5 Other Issues

The previous rules can be applied to allow all combinations of traffic. If the subscriber’s services are modified, the Bridging configuration might need to be modified accordingly.

It can be interesting to detail the configuration of three special cases:

• More than one downstream interface in a bridge
• 802.1D (re-)marking
• More than one VLAN ID tag for the same downstream interface

II.5.1 More than one Downstream Interface in a Bridge

Referring to the example in Tagged LAN to tagged WAN traffic (VLAN bridging), consider adding other Ethernet interfaces (e.g., Ethernet ports 3 and 4 = instance Device.Ethernet.Interface.3/4) to the Video Phone service. The behavior is the same as for the existing Ethernet port 2 (instance Device.Ethernet.Interface.2).

To achieve this, new entries need to be added for interface Eth-3 and Eth-4. The Bridging model is depicted in Figure 30, while the configuration rules for this situation are summarized in Table 6 and Table 10.

II.5.2 802.1D (Re)-marking

The 802.1Q Tag includes the 802.1D user priority bits field. All the previous cases can also be extended to mark (or re-mark) this 802.1D field. To achieve this, there are different configuration options; one of them is to use the DefaultUserPriority or PriorityRegeneration fields in the Bridge Port object. For untagged frames, more complex rules can be defined referring to the QoS Classification, using the PriorityTagging value. The Bridging configuration rules for marking egress traffic on the upstream interface are summarized in Table 11]. Compare it with Table 6.

II.5.3 More than one VLAN ID Tag Admitted on the Same Downstream Interface

Another scenario that can be further detailed is the case of more than one VLAN ID tag admitted on the same downstream interface. A practical example would be a 2 box scenario, with a User Device generating traffic segregated in multiple VLANs (e.g., a router offering services to the customer), and a Residential Gateway, providing upstream connectivity to the Access Network, with the connection between the two pieces of equipment using an Ethernet interface.

In this case, we assume the User Device is able to tag the different traffic flows, segregating the different services (Voice, Video, …) into different VLANs. The Residential Gateway needs, on the same downstream interface, to be able to receive different VLAN ID and correctly forward or translate to the upstream interface (and vice versa). To achieve this, appropriate Bridging objects need to be configured.

Referring to Figure 31 as an example, assume the case of three VLANs (VLAN ID=x,y,z) offered by a User Device to the Residential Gateway on the same downstream interface (Eth #1). The Residential Gateway bridges two of them (VLAN ID=x,y) and translates the other one (VLAN ID=z) to the upstream interface (VLAN ID=k).

On the Residential Gateway, this can be achieved using a combination of the Bridging objects detailed in the preceding sections, with 3 bridge entries and their related entries. Refer to Figure 32 for the Bridging model and Table 12 for the global configuration.

Appendix III: Wi-Fi Theory of Operation

This section discusses the theory of operations for various technologies in the Wi-Fi domain found within the Device:2 data model.

III.1 Multi-radio and Multi-band Wi-Fi Radio Devices

The WiFi.Radio object description says “This object models an 802.11 wireless radio on a device. If the device can establish more than one connection simultaneously (e.g., a dual radio device), a separate WiFi.Radio instance will be used for representing each physical radio of the device.”

The following sections clarify when multiple WiFi.Radio instances are needed, and the impact on their underlying parameters in the case of multi-radio and/or multi-band devices.

III.2 Definitions

Each physical radio allows the transmission and reception of data on a single Wi-Fi channel at a given time. A single-radio device is able to transmit/receive a packet at a given time only on one Wi-Fi channel. Similarly, a dual-radio device is able to simultaneously transmit/receive data on two Wi-Fi channels. In general, a device with N radios is able to simultaneously transmit/receive data on N Wi-Fi channels.

An important point is that Wi-Fi can operate at different frequency bands, 2.4 GHz, 5 GHz and 6 GHz, as follows:

• Wi-Fi technologies based on IEEE 802.11b/g standard operate on the 2.4 GHz frequency band.
• Wi-Fi technologies based on IEEE 802.11a/ac standard operate on the 5 GHz frequency band.
• Wi-Fi technologies based on IEEE 802.11n standard operate on both the 2.4 and 5 GHz frequency bands.IEEE 802.11n is also called Wi-Fi 4 and High Throughput (HT).
• Wi-Fi technologies based on IEEE 802.11ac standard operate on the 5 GHz frequency band. IEEE 802.11ac is also called Wi-Fi 5 and Very High Throughput (VHT).
• Wi-Fi technologies based on IEEE 802.11ax standard operate on the 2.4, 5 and 6 GHz frequency bands. IEEE 802.11ax is also called Wi-Fi 6 and High Efficiency (HE).

Radios that operate at a single frequency band (e.g., 2.4 GHz only 802.11b/g devices) are called single-band radios. Radios that can operate in two frequency bands (e.g., 802.11a/b/g/n/ac/ax devices) are called dual-band radios, and radios that can operate in three bands (e.g., 802.11ax/Wi-Fi6E devices) are called tri-band radios.

A dual-band device can be a single-radio device if it can be configured to operate at 2.4 or 5 GHz frequency bands. However, only a single frequency band is used to transmit/receive at a given time. In such a case the device has a single physical radio that is dual-band.

Also, a dual-radio single-band device can exist (although uncommon) if both radios are single-band.

III.3 Number of Instances of WiFi.Radio Object

Given the definitions above, a separate WiFi.Radio instance will be used for each physical radio of the device, i.e., one instance for a single-radio device, two instances for dual-radio devices, and so on. A single WiFi.Radio instance will therefore be used for a dual-band single-radio device.

Each WiFi.Radio instance is configured separately and is, in general, completely independent of other instances.

III.4 SupportedFrequencyBands and OperatingFrequencyBand

The frequency band used by a WiFi device is an important parameter. With first generations of WiFi technologies, the specific frequency band was linked to the IEEE standard in use (i.e., 802.11b/g are 2.4 GHz standards, while 802.11a is a 5 GHz standard). With the introduction of the IEEE 802.11n standard, which can work both at 2.4 and 5 GHz, two specific parameters are used to indicate the supported frequency bands and the operating frequency band.

SupportedFrequencyBands is a list-valued parameter, containing one item for single-band radios (either 2.4GHz, 5GHz, or 6GHz) and two items for dual-band radios. 802.11ax can also operate in the 6 GHz band.

The OperatingFrequencyBand parameter specifies which frequency band is currently being used by a dual-band radio (i.e., set to one of the two items listed in the SupportedFrequencyBands parameter). For single-band radios, OperatingFrequencyBand always has the same value as SupportedFrequencyBands (since only one frequency band is supported).

III.5 Behavior of Dual-band Radios when OperatingFrequencyBand Changed

When the configured operating frequency band of a dual-band radio is changed (i.e., the value of the OperatingFrequencyBand parameter is modified), this has an impact on other parameters within the WiFi.Radio object.

The Channel parameter has to be changed, since channels for the 2.4 GHz frequency band are in the range 1-14, while channels for the 5 GHz frequency band can be in the range of 36-165 (for example). The expected behavior is that, upon modifying the OperatingFrequencyBand parameter, the device automatically selects a new channel that is valid for the new frequency band (according to some vendor-specific selection procedure).

Other related parameters of significance for the Channel properties are AutoChannelEnable, OperatingChannelBandwidth and CurrentOperatingChannelBandwidth.

Persistence of the Channel parameter value for the previous frequency band is not required. For example, if OperatingFrequencyBand is later changed back to 5GHz, a new valid value for the Channel parameter is automatically selected by the device, but this value need not be the same as was selected the last time OperatingFrequencyBand was set to 5GHz.

Other parameters whose values can be impacted when the OperatingFrequencyBand changes, include: ExtensionChannel, PossibleChannels, SupportedStandards, OperatingStandards, IEEE80211hSupported, and IEEE80211hEnabled. If the current value is no longer valid, the device will automatically select a valid new value according to some vendor-specific procedure, and the old value need not persist.

III.6 SupportedStandards and OperatingStandards

The SupportedStandards parameter is a list of all IEEE 802.11 physical layer modes supported by the devices. Wi-Fi is in general backward compatible, so 802.11g devices are also 802.11b devices, 802.11n devices are also 802.11b/g devices (if operating at 2.4 GHz), and 802.11n devices are also 802.11a devices (if operating at 5 GHz).

For dual-band radios, the OperatingFrequencyBand parameter is used for switching the operating frequency band. For this reason SupportedStandards only includes those values corresponding to operation in the frequency band indicated by the OperatingFrequencyBand parameter. For example, for dual-band 802.11a/b/g/n devices, SupportedStandards can be b, g, n when OperatingFrequencyBand is 2.4GHz and a, n, ac, ax when OperatingFrequencyBand is 5GHz. In addition an 802.11ax device can support tri-band operation in the 2.4, 5, and 6 GHz bands.

The OperatingStandards parameter is used to limit operation to a subset of physical modes supported. For example, an 802.11b/g/n radio will have b, g, n value for the SupportedStandards parameter, but can be configured to operate only with 802.11n by setting the OperatingStandards parameter to n.

III.7 Different Types of WiFi Errors

This section first describes the different WiFi data units and the layers where they apply.

The MAC Service Data Unit (MSDU) is the service data unit that is received from the logical link control (LLC) sub-layer which lies above the medium access control (MAC) sub-layer in the protocol stack.

The MAC protocol data unit (MPDU) is a message exchanged between MAC entities in a communication system. “WiFi frames” refer to MPDUs and WiFi counters are counts of MPDUs.

The Physical Layer Convergence Procedure (PLCP) protocol data unit (PPDU) corresponds with the bits that are actually transmitted across the physical layer.

The MSDU is the frame that interfaces to higher layers, while the MPDU is the frame that is actually transmitted through the wireless medium, excluding the physical layer overhead. The MPDU is the MSDU plus MAC layer overhead (header, FCS, etc.). The PPDU is the MPDU plus physical layer overhead (preamble, PHY header, etc.).

The number of errored MPDUs is the number of MPDUs without corresponding ACKs. In most cases, the number of MSDUs is the same as the number of MPDUs. However, if fragmentation is enabled, then one MSDU can become multiple MPDUs, and there is one ACK per MPDU, hence multiple ACKs for one MSDU.

With frame aggregation in 802.11n, multiple MPDUs become one aggregated MPDU (A-MPDU). There is usually one block ACK for each A-MPDU, and only the errored MPDU(s) can be retransmitted selectively. In this case the WiFi counters will count the original MPDUs and not the A-MPDUs.

To avoid confusion that may be caused by fragmentation or frame aggregation, “WiFi frames” or packets are all considered here to be MPDUs and WiFi counters refer to MPDUs.

Figure 33 explains the process of the MSDU/MPDU flow structure through the MAC layer of the WiFi receiver.

PLCPErrorCount: This error occurs at point (1) in Figure 33, and is the first error type that can be counted. The PLCPErrorCount is the number of errors in the PLCP headers of the received MPDUs, which is the number of frames for which the parity check of the PLCP header failed.

There are two errors that happen at point (2) of the wireless reception:

• FCSErrorCount: This error occurs at point (2) in Figure 33. After the MPDU passes the PLCP header check, it is passed onto MAC layer validation. The FCSErrorCount is the number of frames for which the Frame Check Sequence (FCS) at the end of the MAC frame was in error.

• InvalidMACCount: This error also occurs at point (2) in Figure 33. The MAC header of the MPDU has a field called ‘Protocol Version’. Currently, it is set to ‘0’. If this number is anything but 0, or the frame type is not data/control/management,’ the InvalidMACCount is incremented.

After verifying that the frame was received without errors, the WiFi receiver will then check if the frame was designated for its own use or not (still MAC layer).

PacketsOtherReceived: This counter is used to catch those MPDUs that are not addressed to this radio. This can be assessed by checking if the ‘Address 1’ field of the 802.11 MAC header contains a MAC address that is associated with this radio, if not then ‘PacketsOtherReceived’ is incremented.

After this step, the AP can also discard duplicate frames or fragments among the frames addressed to it, to simplify higher-level processing.

The ErrorsReceived count is the sum of the PLCPErrorCount plus the FCSErrorCount plus the InvalidMACCount.

III.8 Wi-Fi Data Elements

The Wi-Fi Alliance has specified Wi-Fi CERTIFIED Data Elements [69]. Wi-Fi Data Elements objects are under the Device.WiFi.DataElements. tree. Wi-Fi Data Elements Release 1.0 objects were put into Device:2.13, and Wi-Fi Data Elements Release 2.0 and Release 2.1 objects were put into Device:2.15.

In addition to Wi-Fi Data Elements, additional objects and parameters have been specified in TR-181 which are useful for managing Multi-AP Wi-Fi networks. These were originally in the Device.WiFi.MultiAP. tree, however the Device.WiFi.MultiAP. tree has been deprecated in Device:2.15, with some parameters deleted and other parameters moved into the structure of Wi-Fi Data Elements under the Device.WiFi.DataElements. tree. Objects whose titles contain “MultiAP” are not Wi-Fi Data Elements. These MultiAP objects are in the Device.WiFi.DataElements. tree to simplify the structure and avoid duplication, but they are not specified by the Wi-Fi Alliance.

The structure of Device.WiFi.DataElements. differs somewhat from that of the pre-existing Device.WiFi; and there is some overlap between these structures. Wi-Fi Native predates WiFi.DataElements, and Wi-Fi Native includes WiFi.Radio.{i}., WiFi.SSID.{i}, WiFi.AccessPoint.{i}. and WiFi.EndPoint.{i}. Table 13 shows objects, parameters and commands in WiFi.DataElements which have a corresponding object or parameter in Wi-Fi Native. Note that many objects and parameters in WiFi.DataElements do not have any corresponding object or parameter in Wi-Fi Native and so are not listed in Table 13. Also, commands are only in the USP data model and are not in the CWMP data model. Further, Wi-Fi Data Elements’ Network Device table, Device.WiFi.DataElements.Network.Device.{i}., represents all of the devices within Wi-Fi network while Device.WiFi represents only the Wi-Fi device that is being modeled. Table 14 similarly shows objects and parameters in Wi-Fi Native which have a corresponding object or parameter in WiFi.DataElements.

III.9 Incorporating Wi-Fi Data Elements into TR-181

This section discusses the Theory of Operation for representing the Wi-Fi Alliance (WFA) Data Elements (DE) data model [69] using the Device.WiFi.DataElements object. The WFA DE specification provides a data model that can be used to represent a single access point or a multi access point network.

III.9.1 Data Sources for Wi-Fi Data Elements

The DataElements object may be populated by data from any of the following sources:

• IEEE 1905.1 implementation
• WFA DE Agent implementation (for information from the local device, only)
• WFA Multi Access Point Controller implementation
• Network interface card device drivers (for information from the local device, only)
• Application (e.g., a topology database application) that gets data from any of the above sources

Whatever source is used to acquire the data, the data will be represented according to the DE specification [69].

III.9.2 Mapping new Wi-Fi Data Elements objects and parameters

The YANG representation of WFA DE is considered the normative reference to use for mapping purposes.

For the initial mapping (included in Release 13), the names of YANG grouping nodes were used for the TR-181 object names, instead of the names of the lists and containers that used these groupings. This was done because the names of the groupings were consistent with TR-181 naming conventions and there was a one-to-one mapping of grouping to a list or a container. For subsequent mapping, the names of containers and lists will be used, and not groupings.

Wi-Fi Data Elements objects and parameters will be added according to the following rules when WFA defines new nodes:

• YANG “container” and “list” nodes will be mapped to TR-181 “object” elements within the DataElements object hierarchy.
  • If the YANG name of the container or list complies with TR-181 naming conventions specified in [4] section 3.1, the exact name will be used for the TR-181 object name. If the name does not comply, the container or list cannot be automatically added, and an appropriate compliant name will need to be identified.
  • The YANG container or list description can be used “as is” for an automated mapping to the object description, but BBF may modify it slightly for grammar preferences, to include bibliographic references, or to add other useful information when the new object is included in a published revision of TR-181. BBF may also use the grouping description used by the container or list, if this is more descriptive.
  • If the YANG “config true” statement is present, the object will be ‘access=“readWrite”’. Otherwise, the object will be ‘access=“readOnly”’.
  • For all multi-instance objects, the TR-181 model will include a parameter named “<object name>NumberOfEntries” of type unsignedInt in the parent object.
• YANG “leaf” nodes will be mapped to TR-181 “parameter” elements within the DataElements. hierarchy.
  • Put under the “object” that corresponds to the YANG container or list
  • If the YANG name of the leaf complies with TR-181 naming conventions specified in [4] section 3.1, the exact name will be used for the TR-181 parameter name. If the name does not comply, the leaf cannot be automatically added, and an appropriate compliant name will need to be identified.
  • The YANG leaf description can be used “as is” for an automated mapping to the parameter description, but BBF may modify it slightly for grammar preferences, to include bibliographic references, or to add other useful information when the new parameter is included in a published revision of TR-181. Descriptions from DE-custom data type definitions are also mapped into the parameter description.
  • “NumberOf<grouping>” leaf nodes are not mapped. See final bullet of above mapping for containers and lists for inclusion of “<object name>NumberOfEntries” parameter in the TR-181 data model.
  • Data Types are mapped as follows:
    • zero-based-counter32 (and any DE-custom data types based on this, such as bytecounter_t, packetcounter_t) to StatsCounter64 [Note that the TR-181 convention is to use StatsCounter64 for all counters.]
    • uint8 (and any DE-custom data types based on this, such as rssi_t, noisepower_t, operatingclass_t, channel_t, utilization_t) to unsignedInt with range indicated by minInclusive and maxInclusive, if identified
    • uint16 (and any DE-custom data types based on this, such as reasoncode_t, statuscode_t, vlanid_t, pcp_t) to unsignedInt with range indicated by minInclusive and maxInclusive, if identified
    • uint32 to unsignedInt with range indicated by minInclusive and maxInclusive, if identified
    • gauge32 (and any DE-custom data types based on this, such as phyrate_t, macrate_t) to unsignedInt
    • int8 (and any DE-custom data types based on this, such as txpower_t) to int with ranges, if identified (e.g., int[-127:127] for txpower_t)
    • string to string with length indicated by maxLength, if identified
    • mac-address to MACAddress
    • binary to base64
    • boolean to boolean
    • ipv4-address to IPv4Address
    • ipv6-address to IPv6Address
    • additional mappings for data types not listed may be defined by WFA or BBF
• YANG “leaf-list” nodes are mapped like “leaf” elements for name and description with syntax of “<list/>”. The data type is mapped as described above for leaf nodes.

III.10 Wi-Fi Sensing Service

Wi-Fi Sensing is a feature that allows sensing of environmental characteristics such as presence and motion from changes in RF propagation measured using Wi-Fi waveforms. Implementing the functionality spans all layers from the application layer down to the MAC and PHY layers. Because of the scope required, a Wi-Fi Sensing Service component has been introduced, along with an application focused data model (Device.WiFi.Sensing.).

The Wi-Fi Sensing Service is a functional component that provides support for one or more sensing applications to configure and obtain measurements. When present, it acts as a broker between a sensing application and the underlying Wi-Fi Sensing functionality.

A sensing measurement contains a representation of RF propagation between two Wi-Fi devices, which is processed by a sensing application to estimate changes of physical objects within the corresponding environment. Sensing measurements are obtained through coordinated “exchanges” that are performed between two Wi-Fi devices. An exchange is configured and controlled using Wi-Fi EasyMesh [70] features. The Wi-Fi Sensing Service enables grouping of one or more exchanges requested by the same sensing application into a “session”.

A sensing application interacts with the Wi-Fi Sensing Service using the objects under the Device.WiFi.Sensing. tree. A sensing application may first identify itself to the Wi-Fi Sensing Service by invoking the Device.WiFi.Sensing.CreateSession() (USP) command, which triggers the creation of a new session. When triggered, the Wi-Fi Sensing Service will assign a unique session identifier (SessionID), and create a data socket (DataSocketPath) that is used to deliver all sensing measurements requested by the sensing application. The details of each session are stored in Device.WiFi.Sensing.Session.{i}.. The interaction between a sensing application and the Wi-Fi Sensing Service is shown in Figure 34.

Once the sensing application has created a session with the Wi-Fi Sensing Service, it may begin requesting specific sensing measurements be made by adding an exchange to the session by invoking the Device.WiFi.Sensing.Session.{i}.AddExchange() (USP) command. When called, the Wi-Fi Sensing Service will leverage the underlying Wi-Fi sensing features to add the exchange (see Add Exchange). Further, where applicable, the Wi-Fi Sensing Service will obtain the sensing measurements and deliver them to the data socket (DataSocketPath) corresponding to the session to which the exchange belongs (see Sensing Measurement Delivery). The details of each exchange are stored in Device.WiFi.Sensing.Session.{i}.Exchange.{i}..

An exchange may be removed explicitly by the sensing application, or implicitly through uncontrollable events. A sensing application may inform the Wi-Fi Sensing Service that it wishes to explicitly remove an exchange by invoking the Device.WiFi.Sensing.Session.{i}.RemoveExchange() (USP) command (see Explicit exchange removal). In the case where a previously created exchange no longer has the resources available to continue performing measurements (e.g., a device has left the network), then the sensing application will need to be informed by the Wi-Fi Sensing Service (see Implicit exchange removal).

Finally, when the sensing application terminates or no longer needs sensing resources allocated, it may communicate this to the Wi-Fi Sensing Service by invoking the Device.WiFi.Sensing.RemoveSession() USP command. When called, the Wi-Fi Sensing Service will remove all corresponding exchanges, and close the data socket as illustrated in Figure 35.

III.10.1 Exchange Management

There are multiple exchange types defined and enabled by Wi-Fi EasyMesh [70]. Wi-Fi Data Elements objects and USP commands under the Device.WiFi.DataElements. tree provide the Wi-Fi Sensing Service access to those features to handle requests such as adding a new exchange (Add Exchange), removing an existing exchange (Explicit exchange removal), and informing the Wi-Fi Sensing Service that an exchange has been implicitly removed (Implicit exchange removal).

III.10.1.1 Add Exchange

The Wi-Fi Sensing Service is triggered to add the exchange through the Device.WiFi.Sensing.Session.{i}.AddExchange() (USP) command. An example illustrating how this command may be handled is shown in Figure 36. In this figure, the Wi-Fi Sensing Service will first generate a new unique exchange identifier (SensingExchangeID), and then attempt to map the TransmitterMACAddress and ReceiverMACAddress values to the corresponding Wi-Fi Data Elements objects, and invoke the appropriate Device.WiFi.DataElements.Network.Device.{i}.SensingExchangeRequest() (USP) command. This command will trigger the EasyMesh Controller to generate and send an EasyMesh message to the required EasyMesh Agent to request adding the exchange, and ultimately output a result code (ResultCode). The result code is then provided to the sensing application by the Wi-Fi Sensing Service through the asynchronous output of the Device.WiFi.Sensing.Session.{i}.AddExchange() USP command.

There is a special case that involves adding a TriggerBased exchange where either the TransmitterMACAddress or ReceiverMACAddress is that of an unassociated AgentSTA. In this case, the Wi-Fi Sensing Service will need to coordinate between two EasyMesh Agents in order to add the exchange. An example illustrating how this case may be handled is shown in Figure 37. In this figure, the Wi-Fi Sensing Service will first invoke the appropriate Device.WiFi.DataElements.Network.Device.{i}.Radio.{i}.AgentSTA.{i}.SensingMQ() USP command, which instructs the AgentSTA to begin transmitting a Sensing Measurement Query frame to the BSS. Next, the Wi-Fi Sensing Service will invoke the appropriate Device.WiFi.DataElements.Network.Device.{i}.SensingExchangeRequest() USP command, which instructs the BSS to respond to the Sensing Measurement Query frame and create an exchange. The results from both the SensingMQ() and SensingExchangeRequest() (USP) commands are received by the Wi-Fi Sensing Service, and used to inform the sensing application of the status through the asynchronous output of the Device.WiFi.Sensing.Session.{i}.AddExchange() (USP) command.

III.10.1.2 Explicit exchange removal

A sensing application may decide to explicitly remove an exchange from a session if the measurements are no longer needed by triggering the Wi-Fi Sensing Service using the Device.WiFi.Sensing.Session.{i}.RemoveExchange() USP command. An example illustrating how this command may be handled is shown in Figure 38. In this example, the Wi-Fi Sensing Service will map the exchange identified by the SensingExchangeID parameter to the corresponding Wi-Fi Data Elements objects, and invoke the appropriate Device.WiFi.DataElements.Network.Device.{i}.SensingExchangeRequest() (USP) command. This command will then trigger the EasyMesh Controller to generate and send an EasyMesh message to the appropriate EasyMesh Agent to request removing the exchange, and ultimately output a result code (ResultCode). The result code is finally provided to the sensing application by the Wi-Fi Sensing Service through the notification event Device.WiFi.Sensing.Session.{i}.ExchangeTerminated! as an indication that the exchange was successfully removed.

III.10.1.3 Implicit exchange removal

In the case where a previously created exchange no longer has the resources available to continue performing measurements (e.g., a device has left the network), then the Wi-Fi Sensing Service will be notified by receiving a Device.WiFi.DataElements.Network.Device.{i}.SensingExchangeResponse! event, which was generated in response to the EasyMesh Controller receiving an unsolicited Sensing Exchange Response TLV. The Wi-Fi Sensing Service will then inform the sensing application by generating a Device.WiFi.Sensing.Session.{i}.ExchangeTerminated! notification event as shown in Figure 39.

III.10.2 Sensing Measurement Delivery

The Wi-Fi Sensing Service is also responsible for delivering the sensing measurements to the appropriate sensing application that is listening to the Device.WiFi.Sensing.Session.{i}.DataSocketPath. On a system where multiple sensing applications may be operating concurrently, it is important that each application only receive the sensing measurements from exchanges added to its session.

Typically, sensing measurements are received by the EasyMesh Agent, and optionally sent in a defined containerized format to a Layer3Path (see [70] for more information). The container format includes an SensingExchangeID field, which matches the unique SensingExchangeID belonging to each configured exchange.

Depending on the configured exchanges, the Wi-Fi Sensing Service may need to create a new Layer3Path connection with an EasyMesh Agent by invoking the Device.WiFi.DataElements.Network.Device.{i}.SetupLayer3Path() USP command. Once established, the Wi-Fi Sensing Service may connect to the Layer3Path output to receive the resulting sensing measurements. Since a single Layer3Path may be used to transfer sensing measurements belonging to multiple sessions, it is the job of the Wi-Fi Sensing Service to identify the sensing measurements from the container’s SensingExchangeID field, and match that with the corresponding session. If there are no longer any exchanges corresponding to a specific Layer3Path, the Wi-Fi Sensing Service may remove the unused Layer3Path through the Device.WiFi.DataElements.Network.Device.{i}.RemoveLayer3Path() USP command.

Appendix IV: Use Cases

This section presents a number of management-related use cases that correspond to typical Controller activities.

IV.1 Create a WAN Connection

The Controller can create the objects in the interface stack bottom-up. Each time a new higher-layer object is created, the link with the underlying interface object needs to be set. The layer 1 interface, in this case a DSL.Channel and DSL.Line object, will already exist (A Controller cannot create physical interfaces).

1. The Controller creates a new ATM.Link object, a new Ethernet.Link object, a new PPP.Interface object, and a new IP.Interface object.

2. The LowerLayers parameter in an existing DSL.Channel object is already linked to an existing DSL.Line object (A Controller cannot configure this linkage).

3. The Controller configures the new objects including enabling the objects and using the LowerLayers parameters as follows:

   • Setting the LowerLayers parameter in the ATM.Link object to link it to an existing DSL.Channel object that is configured with ATM encapsulation (i.e., the read-only LinkEncapsulationUsed parameter in the DSL.Channel object is set to one of the ATM-related enumeration values).
   • Setting the LowerLayers parameter in the Ethernet.Link object to link it to the ATM.Link object.
   • Setting the LowerLayers parameter in PPP.Interface object to link it to the Ethernet.Link object.
   • Setting the LowerLayers parameter in IP.Interface object to link it to the PPP.Interface object.

4. The device updates the InterfaceStack table automatically. The stack looks like this: IP.Interface → PPP.Interface → Ethernet.Link → ATM.Link → DSL.Channel → DSL.Line.

5. Note that the Controller might also want to update other related objects, including the NAT object, the Routing.Router object, or various QoS and Bridging tables. VLANs might also need to be created.

IV.2 Modify a WAN Connection

In this use case, the Controller needs to modify an existing WAN connection, in order to insert a new layer in the stack or to change some portion of the interface stack. This is not the management WAN connection. For the purposes of this example, the Controller is changing the WAN connection in the Create a WAN Connection use case to make use of PTM rather than ATM-based aggregation.

1. The Controller creates a new PTM.Link object.

2. The Controller configures the objects, including enabling the new PTM.Link object and using the LowerLayers parameter as follows:

   • Setting the LowerLayers parameter in the PTM.Link object to link it to an existing DSL.Channel object that is configured with PTM encapsulation (i.e., the read-only LinkEncapsulationUsed parameter in the DSL.Channel object is set to one of the PTM-related enumeration values).
   • Setting the LowerLayers parameter in the Ethernet.Link object to refer to the PTM.Link object rather than the ATM.Link object.
   • Setting the LowerLayers parameter in the IP.Interface object to refer to the Ethernet.Link object rather than the PPP.Interface object.

3. The device updates the InterfaceStack table automatically. The stack looks like this: IP.Interface → Ethernet.Link → PTM.Link → DSL.Channel → DSL.Line.

4. Note that the Controller might also want to update other related objects, including the Bridging table. The Controller might also want to delete the existing PPP.Interface and ATM.Link objects.

IV.3 Delete a WAN Connection

Assume that we want to delete the WAN connection as it is configured in the Create a WAN Connection use case.

1. The Controller deletes the IP.Interface object.

2. The Controller deletes the PPP.Interface object.

3. The Controller deletes the Ethernet.Link object.

4. As each of these objects is deleted, the InterfaceStack is adjusted automatically by the device.

5. Any strong references to the deleted objects, e.g., in Device.QoS classification rules, will automatically be set to empty strings.

IV.4 Discover whether the Device is a Gateway

Many operators want to determine if a particular device is a “gateway” or not. The term “gateway”, however, is rather vague; usually the operator wants to know one (or more) of the following things:

1. If the device terminates the WAN connection(s).

2. If the device is responsible for providing DHCP addresses to the other devices in the home.

3. If the device provides functionality such as NAT or routing capabilities.

In order to determine if the device terminates a WAN connection, the Controller might look for an interface object with a technology that is by definition WAN (such as DSL) or for a technology that could be a WAN termination technology (such as Ethernet or MoCA).

In order to determine if the device is responsible for providing addresses to other devices in the home, the Controller could check for the existence of the DHCP Server object. The existence of the Host table also indicates that the device is aware of Hosts, by whatever means they’re addressed.

For CWMP managed devices, the existence of the ManageableDevice table within the ManagementServer object also indicates that the device serves as the DHCP server for the TR-069 managed device exchange defined in TR-069 [2] Annex F, which is also often an indication of “gateway” functionality.

In order to determine if the device provides functionality such as NAT or a router, the Controller would check for the existence of an enabled NAT or Routing.Router object.

IV.5 Provide Extended Home Networking Topology View

Another use case is to determine the topology of the home network behind the gateway. For a generic understanding of the network, the Host table provides information such as the layer 2 and layer 3 interfaces via which the Host is connected as well as DHCP lease information for each connected Host.

If the operator is interested in UPnP devices in the home network, the UPnP.Discovery tables (RootDevice, Device, and Service) provide that information in addition to the Host table entries that correspond to a particular UPnP Root Device, Device, or Service.

Finally for CWMP enabled devices, the ManageableDevice table within the ManagementServer object provides information about the CWMP managed devices that the device has learned about through the DHCP message exchange defined in TR-069 [2] Annex F.

IV.6 Determine Current Interfaces Configuration

One of the most fundamental Controller tasks is to determine the general picture of the interfaces for a device so that it can understand which WAN and LAN side connections exist.

In the Device:2 data model managed with CWMP, it would work this way:

1. The ACS would issue a GetParameterValues for the InterfaceStack table. This table would provide a list of all the Interface connections. The ACS could use this table to build up the general picture of the Interfaces that are part of the current configuration.

2. If the ACS is interested in the specifics of an individual interface, it can then go and issue GetParameterNames or GetParameterValues for the interfaces of interest.

If the device is managed by USP:

1. The USP Controller would issue a Get request for the InterfaceStack table. This table would provide a list of all the Interface connections. The USP Controller could use this table to build up the general picture of the Interfaces that are part of the current configuration.

2. If the USP Controller is interested in the specifics of an individual interface, it can then go and issue a filtered Get request message for the interfaces of interest.

IV.7 Create a WLAN Connection

In this use case the Controller creates a new WLAN connection. For the purposes of illustration, in this example the Controller will create a new SSID object to link to an existing radio (a new SSID object implies a different SSID value than those used by existing WiFi connections). The layer 1 interface, in this case a WiFi.Radio object, will already exist (Controller can not create physical interfaces).

1. The Controller creates a new WiFi.SSID object and WiFi.AccessPoint object.

2. The Controller configures the new WiFi.SSID object, including enabling it and setting the value of the LowerLayers parameter to reference the device’s WiFi.Radio object.

3. The Controller adds the new WiFi.SSID object to the LowerLayers parameter of an existing non-management Bridging.Bridge.{i}.Port object, as appropriate.

   A non-management bridge port is indicated when its ManagementPort parameter is set to false.

4. The Controller configures the new WiFi.AccessPoint object, including enabling it and sets the value of its SSIDReference parameter to reference the WiFi.SSID object.

5. The device updates the InterfaceStack table automatically.

6. Note that the Controller might also want to update other related objects; also, if there were no appropriate existing bridge port to which to connect the SSID, the Controller might need to create that object as well.

IV.8 Delete a WLAN Connection

In this use case the Controller deletes the SSID created in the Create a WLAN Connection use case.

1. The Controller deletes the WiFi.SSID object and the WiFi.AccessPoint object.

2. The device automatically updates the InterfaceStack table.

3. Note that if the radio has no other SSIDs configured, this would operationally disable the wireless interface.

IV.9 Configure a DHCP Client and Server

In this use case, the Controller wants to configure a DHCP server to provide private 192.168.1.x IP addresses to most home network (HN) devices, but to obtain IP addresses from the network for HN devices that present an option 60 (vendor class ID) value that begins with “ACME”.

The ACME devices are remotely managed, so the Controller will also configure the DHCP clients on those devices and the DHCP server on the gateway.

IV.9.1 DHCP Client Configuration (ACME devices)

The ACME devices are quite simple. Each has a single wired Ethernet port and a single IP interface.

A DHCP Client object is created and configured as follows:

IV.9.2 DHCP Server Configuration (gateway)

The gateway is also relatively simple. Its downstream IP interface is IP.Interface.1.

A DHCP Server object is created and configured as follows:

If a DHCP request includes an option 60 value that begins with “ACME”, the request is forwarded to the DHCP server at 1.2.3.4. All other requests are served locally from the pool 192.168.1.64 - 192.168.1.254 (excluding 192.168.1.128 and 192.168.1.129).

IV.10 Reconfigure an Existing Interface

The Controller might want to reconfigure an existing Interface to provide alternate routing functionality. For the purposes of this illustration, an existing Ethernet Interface that is configured for the downstream-side will be reconfigured as an upstream Ethernet Interface replacing an existing DSL Interface.

The current configuration on the upstream side looks like:

IP.Interface.1 → Ethernet.Link.1 → ATM.Link.1 → DSL.Channel.1 → DSL.Line.1

The current configuration on the downstream side contains:

• IP.Interface.2 → Ethernet.Link.2 → Bridging.Bridge.1.Port.1 (ManagementPort=true)
• Bridging.Bridge.1.Port.1 LowerLayers parameter has two references:
  • Bridging.Bridge.1.Port.2
  • Bridging.Bridge.1.Port.3
• Bridging.Bridge.1.Port.2 LowerLayers parameter has a reference of Ethernet.Interface.1
• Bridging.Bridge.1.Port.3 LowerLayers parameter has a reference of Ethernet.Interface.2

The Controller would follow these steps to reconfigure the Ethernet.Interface:

1. Determine which Ethernet.Interface is to be reconfigured. For the purpose of this illustration we will use Ethernet.Interface.1.

2. Retrieve the InterfaceStack.

3. Find the higher-layer Interface of Ethernet.Interface.1 by finding the InterfaceStack entry that has Ethernet.Interface.1 as the LowerLayer. The HigherLayer parameter of the identified InterfaceStack instance will be the Interface we are interested in, for the purpose of this illustration we found Bridging.Bridge.1.Port.2.

4. Remove the Bridging.Bridge.1.Port.2. This removal will automatically clean up the InterfaceStack instances that connect Bridging.Bridge.1.Port.1 → Bridging.Bridge.1.Port.2 and Bridging.Bridge.1.Port.2 → Ethernet.Interface.1. Also, it will remove Bridging.Bridge.1.Port.2 from the LowerLayers parameter contained within Bridging.Bridge.1.Port.1.

5. Find the DSL.Line reference within the LowerLayer parameter of the InterfaceStack.

6. Follow the InterfaceStack up to the Ethernet.Link reference by looking at the HigherLayer parameter in the current InterfaceStack instance and then finding the InterfaceStack instance containing that Interface within the LowerLayer parameter until the HigherLayer reference is the Ethernet.Link Interface. For the purpose of this illustration, we found Ethernet.Link.1.

7. Reconfigure the LowerLayers parameter of Ethernet.Link.1 such that its value is “Device.Ethernet.Interface.1” instead of “Device.ATM.Link.1”.

8. The device updates the InterfaceStack table and sets the Upstream parameter to true on the Ethernet.Interface.1 instance automatically.

9. Note that the Controller might also want to update other related objects, including the NAT object, the Routing.Router object, or various QoS and Bridging tables. VLANs might also need to be created.

After the CWMP Session is completed and the device commits the configuration, the upstream side will look like:

• IP.Interface.1 → Ethernet.Link.1 → Ethernet.Interface.1

IV.11 Backup / Restore Using Vendor Configuration Files

In certain troubleshooting scenarios, a Device that has its user configuration modified in a manner that cannot be easily restored by setting individual parameters can have the Device’s user configuration restored by applying a previous user configuration to the Device. When performing a backup and restoration of configuration files, the Controller can correlate the instance number of the VendorConfigFile retrieved during backup (Upload RPC) operation with the URL of the restore (Download) operation. The following sequence diagrams depict a backup and restoration scenario that correlates these attributes of a configuration file.

Figure 40 depicts a message sequence scenario where a configuration is backed up from the Device to the ACS using CWMP.

Step 1: Retrieve instances and values of VendorConfigFile and DeviceInfo:

The parameter values of the DeviceInfo and VendorConfigFile provide the information necessary to restore a Device to a point in time. Minimally the information needed to create a snapshot includes:

• Device.DeviceInfo.ManufacturerOUI
• Device.DeviceInfo.ProductClass
• Device.DeviceInfo.SerialNumber
• Device.DeviceInfo.HardwareVersion
• Device.DeviceInfo.SoftwareVersion
• Device.DeviceInfo.VendorConfigFile.{i}. (Entire object)
• Device.SoftwareModules.DeploymentUnit.{i}.UUID
• Device.SoftwareModules.DeploymentUnit.{i}.Alias
• Device.SoftwareModules.DeploymentUnit.{i}.Name
• Device.SoftwareModules.DeploymentUnit.{i}.Version
• Device.SoftwareModules.DeploymentUnit.{i}.VendorConfigList

This information is necessary as restoring Device configurations with different hardware versions, software versions or deployment units that existed at the time of the backup can result in a failed restoration attempt or a corrupted Device.

Step 1a: The parameters returned by the Device in the GetParameterValuesResponse are used to create a “snapshot” of the Device. The definition of what is needed to create a snapshot and how a snapshot is administered in an ACS is implementation specific.

Step 2: Backup each configuration file defined by the Device in the VendorConfigFile table with the UseForBackupRestore parameter set to the value “true” using the Upload RPC with a File Type “3 Vendor Configuration File x” where “x” is the instance number of the file in the VendorConfigFile table.

Step 3, 3a: Upon completion of the transfer for each file via the Transfer Complete event, the ACS will update the state of the snapshot. The lifecycle and state management of the snapshot by an ACS is implementation specific.

At this point a Device snapshot exists that can be used to restore a Device to this point in time.

Figure 41 depicts a message sequence scenario where a configuration is restored to the Device from the ACS

Step 1: For each user configuration file in the snapshot, retrieve the information for the location of the configuration file.

Step 2, 2a: Download the configuration using the File Type “3 Vendor Configuration File” and the location of the configuration file.

Step 3, 3a: The Device performs the download of each configuration file and responds with a Transfer Complete event.

Appendix V: IPv6 Data Modeling Theory of Operation

The Device:2 data model supports IPv6 (introduced in Amendment 2) via various IPv6-specific objects and parameters that are designed to be used with other IP version neutral and IPv4-specific objects and parameters. This Appendix briefly reviews all the relevant objects and parameters, and then presents some example configurations.

V.1 IPv6 Overview

The IETF published RFC 2460 [24], Internet Protocol, Version 6 (IPv6) Specification in 1998. Since then, it has published a variety of RFCs to create a suite of protocols (and extensions to protocols) for operating, managing, and configuring IPv6 networks and devices. In addition there are RFCs that document transition mechanisms (to transition from IPv4 to IPv6) and best current practices (that describe which RFCs to implement depending on what a device is or needs to do).

The Broadband Forum has published several Technical Reports describing IPv6 architectures and device requirements. Specifically, TR-124 Issue 2 [5] includes IPv6 requirements for Residential Gateways (RGs), TR-177 [7] describes migration to IPv6 in the context of TR-101 [3], and TR-187 [8] describes an architecture for IPv6 for PPP Broadband Access. The Device:2 IPv6 Data Model is intended to ensure that TR-069 [2] or USP [11] managed End Devices, RGs, and other Network Infrastructure Devices can be managed and configured, consistent with the requirements listed in these documents.

The basic elements of IPv6 data modeling involve information on IPv6 capabilities, and enabling those capabilities on devices and device interfaces (see Enabling IPv6), configuring addresses, prefixes , and configuration protocols on upstream and downstream interfaces (see Configuring Upstream IP Interfaces and Configuring Downstream IP Interfaces), interacting with other devices on the Local Area Network (LAN) (see Device Interactions), and configuring IPv6 routing and forwarding information (see *[Configuring IPv6 Routing and Forwarding*]).

Configuration protocols include Neighbor Discovery (ND; RFC 4861 [46]) and DHCPv6 (RFC 3315 [33]). Neighbor Discovery includes several messages that are important to configuration, including Router Solicitation (RS) [sent by devices looking for routers], Router Advertisement (RA) [sent by routers to other devices on the LAN], Neighbor Solicitation (NS) [used to identify if any other device on the LAN is using the same IPv6 address, and used to see if previously detected devices are still present; the latter is called Neighbor Unreachability Detection (NUD)], and Neighbor Advertisement (NA) [used to respond to a NS sent to one of the device’s IPv6 addresses]. These messages are central to the stateless address autoconfiguration (SLAAC) mechanism described in RFC 4862 [47]. SLAAC is expected to be the primary means of IPv6 address configuration for devices inside a home network. RFC 4191 [39] extended the RA message to support a RouteInformation option. RFC 6106 [53] extended the RA message to support sending Recursive DNS Servers (RDNSS) information for DNS configuration.

DHCPv6 can also be used for IPv6 address provisioning, through its IA_NA option. DHCPv6 was extended by RFC 3633 [35] to provide the IA_PD option for delegating IPv6 prefixes to routers (that the routers can then use to provide IPv6 addresses to other devices on the LAN, or to further sub-delegate to other routers inside the LAN). Both IA_NA and IA_PD require the DHCPv6 server to maintain state for these assignments (since they have lifetimes, can expire, and require renewal). DHCPv6 can also supply a variety of stateless configuration options, including recursive DNS server information. RGs can have both DHCPv6 client and server, and it may be desirable for some of the stateless options to be passed through from the client to the server.

Interfaces that support IPv6 will have more than one IPv6 address. IPv6 interfaces are always required to have a link-local address (described in RFC 4862 [47]). Other IPv6 addresses may be acquired through SLAAC, DHCPv6 IA_NA, or they may be statically configured. Routers may acquire prefixes (for use with address assignment in the LAN) from DHCPv6 IA_PD, static configuration, or by generating their own Unique Local Address (ULA) prefixes from a self-generated ULA Global ID (RFC 4193 [40]).

Because of the various IPv6 addresses that devices can have, maintaining good routing table and IPv6 forwarding information is critical. Route information can be obtained from received RA messages (both by noting that the sending device is a router, and from the RouteInformation option) as well as other protocols.

V.2 Data Model Overview

This Theory of Operations focuses on data modeling for the purpose of establishing upstream and downstream connectivity for TR-069 [2] or USP [11] enabled devices, and for configuration of IPv6-related parameters. This is not an exhaustive description of data model changes made in support of IPv6, and only intends to describe the working of elements that are not readily obvious.

The following tables are key to IPv6 data modeling:

Note that the following tables have separate theories of operation, and are not described again here:

Firewall includes some IPv6 elements that are not described, since it does not interact with tables other than an association with IP.Interface. As such, its IPv6 usage is considered straightforward, and explanation is considered unnecessary.

Similarly, DNS.Client.Server is not described.

Use of DHCPv6 elements of Bridging.Filter are also not described, as there is no conceptual difference between how they are used and how DHCPv4 elements are used.

Figure 42 shows the relationship of IPv6 configuration messages to devices and the tables used to configure the protocol messages and store the responses.

Figure 43 shows internal relationships of parts of the data model involved in IPv6 addresses and IPv6 prefixes. The following sections describe in greater detail how these various tables are populated.

V.3 Enabling IPv6

The IP IPv6Capable parameter indicates whether the device supports IPv6. IP.IPv6Enable controls enabling IPv6 is on the device. IPv6 can only be enabled on a device with IPv6Capable=true. IPv6Status indicates whether IPv6 has been enabled on the device.

Per TR-124 Issue 2 [5], the upstream interface can be configured to establish an IPv6 connection either over PPP (PPPoA or PPPoE) or directly over Ethernet. Both mechanisms require an IP.Interface instance with IPv6Enable set to true. When using PPP, a PPP.Interface instance must have IPv6CPEnable set to true (which can only occur if PPP.SupportedNCPs includes IPv6CP in its list of Network Control Protocols (NCPs)).

Enabling IPv6 on specific downstream or upstream interfaces requires that IP.Interface instances have IPv6Enable set to true.

V.4 Configuring Upstream IP Interfaces

An upstream IP Interface is an IP.Interface that is associated with an Upstream=true physical interface, via the InterfaceStack. Every Upstream=true physical interface that will be used to support routed IPv6 traffic will have an upstream IP Interface for each distinct upstream IPv6 connection that is established over that physical interface.

Upstream IPv6 connections can be established on an upstream IP Interface either through internal logic (for well-known addresses and the link-local address), static configuration, or dynamically through received Router Advertisement (RA) messages or DHCPv6 client behaviors. Received RA and DHCPv6 messages can contain configuration information for more than just establishing the upstream IP interface. The data model allows for the storage of additional configuration information sent by one of these protocols.

V.4.1 Configuration Messages Sent Out the Upstream IP Interface

The device can be configured to send Router Solicitation and DHCPv6 client messages out an upstream IP interface.

• A device that is configured to send Router Solicitation messages out an upstream IP interface will have a NeighborDiscovery.InterfaceSetting instance whose Interface is the related upstream IP.Interface, and with RSEnable=true.

• A device that is configured to send DHCPv6 client requests out an upstream IP interface will have a DHCPv6.Client instance whose Interface is the related upstream IP.Interface, and with Enable=true. RequestAddresses indicates whether IA_NA is to be requested, RequestPrefixes indicates whether IA_PD is to be requested, and RequestedOptions identifies which other options are to be requested. DHCPv6.Client.Server, DHCPv6.Client.SentOption, and DHCPv6.Client.ReceivedOption are populated as appropriate, as described in the data model.

V.4.2 IPv6 Prefixes

IP.Interface.IPv6Prefix instances on upstream IP interfaces are used to store all prefixes received in RA messages on the interface (with Origin of RouterAdvertisement), prefixes delegated by DHCPv6 IA_PD (with Origin of PrefixDelegation), statically configured IPv6 prefixes (but only the ones that are intended to be sub-divided for use on downstream interfaces with sent RA messages or DHCPv6 server functions), and WellKnown prefixes, as appropriate (such as certain well-known multicast prefixes, where the device joins the multicast group for that prefix on that interface).

RouterAdvertisement prefixes with Autonomous=true are used to create an IPv6Address instance on the interface, and can be used to create routes in Routing.Router.IPv6Forwarding. RouterAdvertisement prefixes with OnLink=true can also be used to create routes in Routing.Router.IPv6Forwarding. Prefixes received in a RA RouteInformation option are not stored with the interface, but rather in an instance of Routing.RouteInformation.InterfaceSetting.

PrefixDelegation prefixes and Static prefixes are not directly used on the upstream IP interface. They are prefixes that are intended to be sub-divided for use on the device’s downstream interfaces, either by the DHCPv6 server for IA_NA or IA_PD, sent in RA messages (as on-link and/or autonomous prefixes), or used to self-assign addresses to other interfaces on the device. Non IA_PD prefixes received in DHCPv6 options are not stored with the upstream IP interface. Prefixes for static routes are entered directly into Routing.Router.IPv6Forwarding and do not need to also have upstream IP interface IPv6Prefix entries.

It is often desirable to configure information about delegated prefixes before they have been delegated (for example, that a particular /64 of that prefix is to be used on the downstream interface for address assignment). In order to allow for the referencing of not-yet-existing-but-expected delegated prefixes, an Origin=Static IPv6Prefix entry is created of Type=PrefixDelegation. When a device receives a delegated prefix, it is expected to first look for such Static entries and populate them with the delegated prefix information, instead of creating a new IPv6Prefix instance of Origin=PrefixDelegation. How these references are configured on downstream interfaces is discussed in IPv6 Prefixes.

V.4.3 IPv6 Addresses

IPv6 link-local addresses on an upstream IP Interface are generally internally generated, although they can be configured statically, when necessary (when the internal default link-local address fails Duplicate Address Detection (DAD)). A properly configured upstream IP.Interface instance will have a IP.Interface.IPv6Address instance for its link-local address. This will have Origin of AutoConfigured (if internally generated per RFC 4862 [47]) or Static (if statically configured by some management entity).

IPv6 addresses that are created via stateless address autoconfiguration (SLAAC), as defined in RFC 4862 (from received RA messages that contain prefix(es) with Autonomous=true) cause the device to create a IP.Interface.IPv6Address instance with Origin of AutoConfigured. IPv6 addresses assigned via DHCPv6 IA_NA cause the device to create a IP.Interface.IPv6Address instance with Origin of DHCPv6. Statically created IPv6 addresses will have Origin of Static. If any of these addresses are Global Unicast Addresses (GUA), they can be used to originate and terminate traffic to/from either the downstream or the upstream, independent of which physical interface they are associated with.

V.5 Configuring Downstream IP Interfaces

A downstream IP Interface is a IP.Interface that is associated with an Upstream=false physical interface, via the InterfaceStack. As noted in the definition of the Upstream parameter, “For an End Device, Upstream will be true for all interfaces.” This means that only RGs or (possibly) other Network Infrastructure Devices will have downstream IP Interfaces.

V.5.1 IPv6 Prefixes

IP.Interface.IPv6Prefix instances on downstream IP interfaces are used to store all prefixes that are either on-link for that downstream IP interface, or can be delegated to or used by routers connected to that downstream IP interface. On-link prefixes include prefixes that are included in Router Advertisement (RA) messages for SLAAC (Autonomous prefixes), those used as DHCPv6 address pools, and those used for static addressing by End Devices that connect to that downstream IP interface.

The device can have a Unique Local Address (ULA) /48 prefix defined in IP.ULAPrefix. In general, the device will generate its own ULA /48 prefix, although this value could be configured directly by the user or through TR-069 [2] or USP [11]. If ULA addressing is to be supported on a downstream interface, then IP.Interface.ULAEnable must be true. The ULA /48 prefix can be associated with any downstream IP interface, and can be sub-divided to provide ULA prefixes on multiple downstream IP interfaces (by assigning longer prefixes from the ULA /48 prefix to these downstream IP interfaces). When the device creates a ULA prefix on a downstream interface, it creates an IPv6Prefix instance with Origin=AutoConfigured.

RGs that are configured to act as routers need to know which prefixes to include in their sent Router Advertisement (RA) messages and to be used in DHCPv6 server pools. These prefixes need to be associated with the downstream IP interface for those RouterAdvertisement.InterfaceSetting and DHCPv6.Server.Pool instances. These prefixes can be statically configured on the downstream IP interface, or they can be automatically generated from prefixes on an upstream IP interface with Origin of PrefixDelegation or Static, or they can be generated from the ULA /48 prefix (as described in the previous paragraph). Prefixes that are automatically (by internal code) derived from prefixes on an upstream IP interface with Origin of PrefixDelegation or Static, will point to that upstream IP interface in ParentPrefix and have Origin of Child.

It is often desirable to pre-configure information about prefixes on a downstream IP interface that are to be derived from delegated (on the upstream interface) prefixes. This will need to be done before that prefix has been delegated and without knowledge of what that prefix will be. A derived-from-not-yet-existing-but-expected-delegated-prefix downstream IP interface IPv6Prefix entry will have Origin=Static and Type=Child, and will have ParentPrefix pointing to an upstream IP interface IPv6Prefix instance (that is Origin=Static and Type= PrefixDelegation). When a device receives a delegated prefix and populates the upstream IP interface IPv6Prefix instance, and needs to generate downstream IP interface prefixes from that delegated prefix, it is expected to first look for such Static Child entries and populate them with the derived prefix information, instead of creating a new IPv6Prefix instance of Origin=Child. How the referenced parent prefixes are configured on upstream IP interfaces is discussed in IPv6 Prefixes.

If the device receives RA messages on downstream IP interfaces, autonomous and on-link prefixes in such received RA message Prefix Information options can also be recorded in IP.Interface.IPv6Prefix. At this time, there is no additional guidance for using the information in these RA messages received on downstream interfaces. They are simply stored, to provide information about other devices in the home network.

V.5.2 IPv6 Addresses

As with the upstream IP interfaces, IPv6 link-local addresses on a downstream IP interface are generally internally generated, although they can be configured statically, when necessary (when the internal default link-local address fails Duplicate Address Detection (DAD)). A properly configured downstream IPv6 connection will have a IP.Interface instance with a IP.Interface.IPv6Address instance for its link-local address. This will have Origin of AutoConfigured (if internally generated per RFC 4862 [47]) or Static (if statically configured by some management entity).

If the device has a Unique Local Address (ULA) prefix that it is advertising and/or sub-delegating to devices on the LAN, then it needs to have at least one address from this prefix assigned to downstream IP interfaces that expect to support usage of the ULA.

If the device did not receive an address on its upstream IP interface (from DHCPv6 or SLAAC), but it was delegated a prefix (DHCPv6 IA_PD), then it is expected to assign an address from a prefix (Origin=Child or Type=Child) derived from that delegated prefix to one of its non-upstream interfaces. This IPv6Address instance will have Origin of AutoConfigured. This address can be used for originating and terminating messages to and from either the downstream or the upstream interfaces.

V.6 Device Interactions

The RG can interact with other devices on the LAN both by actively sending messages with or without configuration information, and by passively listening to messages received from other devices. End Devices can interact with other devices on the LAN by passively listening to messages received from other devices and by actively performing Neighbor Unreachability Detection (NUD) to determine if previously detected devices are still reachable.

V.6.1 Active Configuration

To assist in the automated configuration of other devices on the LAN, an RG sends Router Advertisement (RA) messages and DHCPv6 server messages. This function is associated with downstream IP interfaces, and thus does not apply to End Devices. As noted in the above section on downstream IP interfaces, only RGs or other infrastructure devices will have downstream IP interfaces.

• RouterAdvertisement.InterfaceSetting instances whose Interface is the related downstream IP.Interface, with Enable=true, define the content of RA messages that get sent on the downstream IP interface. The RouterAdvertisement.InterfaceSetting instance will include references to IPv6Prefix entries in the associated downstream IP interface. These are IPv6Prefix entries of Origin=Child or Origin=Static.

• DHCPv6.Server.Pool instances whose Interface is the related downstream IP.Interface, with Enable=true, contain information for filtering DHCPv6 client requests, and identify the IPv6 prefix(es) (references to IPv6Prefix entries of the associated downstream IP interface) that provide the pool of IPv6 addresses and IPv6 prefixes available for assignment from this pool. Information on soliciting clients (including assigned addresses and prefixes and received option information) is stored in DHCPv6.Server.Pool.Client. Additional options that are sent to soliciting clients is stored in DHCPv6.Server.Pool.Option. The PassthroughClient parameter in this table identifies whether the value of this option is simply passed through from a DHCPv6 client on an upstream interface.

As noted above, both RouterAdvertisement.InterfaceSetting and DHCPv6.Server.Pool have references to IPv6Prefix entries. The ManualPrefixes, IANAManualPrefixes and IAPDManualPrefixes parameters allow for configuration (through TR-069 [2], USP [11], user interface, or other means) of prefixes that are to be included in RA messages, and to be used in deriving DHCPv6 IA_NA and IA_PD offers, respectively. The Prefixes, IANAPrefixes, and IAPDPrefixes parameters list all of the prefixes that the devices actually does include in these messages. Since the *ManualPrefixes entries may point to IPv6Prefix entries that are not enabled, it is possible that not all of those will be included in these parameters’ lists. In addition to the *ManualPrefix entries, these lists may also include references to prefixes that the device creates or uses automatically in RA messages or for deriving DHCPv6 IA_NA or IA_PD offers.

There is some flexibility in the modeling of ULA IA_PD prefixes. It is not required to model the ULA /48 prefix in an IPv6Prefix instance. If the ULA /48 is not represented in an IPv6Prefix instance and ULAEnable is true for a downstream interface and IAPDEnable is true for a DHCPv6.Server.Pool instance, then it can be assumed that the device will sub-delegate prefixes from the ULA /48 prefix. Alternately, the ULA /48 can be included as an AutoConfigured prefix in a downstream interface, and that IPv6Prefix instance can be referenced in IAPDPrefixes in the DHCPv6.Server.Pool instance. It is also possible to manually create a Static longer-than-/48 prefix from the ULA prefix in a downstream interface. This Static prefix can then be referenced in IAPDManualPrefix for a DHCPv6.Server.Pool instance for that interface.

For IA_PD, there is one additional parameter: IAPDAddLength. This parameter is configured to recommend how many bits should be added to an IAPDPrefixes prefix to create a delegated prefix offer.

V.6.2 Monitoring

All devices can monitor and record information from messages sent by other devices.

• Information received in Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages sent by other devices is recorded in Hosts.Host.

• In order to actively solicit information from other devices on the LAN, the device can have a NeighborDiscovery.InterfaceSetting instance whose Interface is the related downstream IP.Interface, and with NUDEnable=true. To determine whether there are other routers connected to the LAN that are behaving like IPv6 routers to this same LAN segment, this InterfaceSetting can also have RSEnable=true. However, it is not recommended that routers do this until there is better guidance available for routers that co-exist in a peered environment on the same LAN.

V.7 Configuring IPv6 Routing and Forwarding

IPv6 routing information is stored in instances of Routing.Router.IPv6Forwarding. This information can in part be derived from Router Advertisement (RA) messages, either directly from the address of the router sending the RA, or from RA RouteInformation (RFC 4191 [39]) options that may be included in the message. Routing.RouteInformation.InterfaceSetting instances record received RA RouteInformation options.

Following is an example of how a typical RG (one upstream and one downstream interface, with delegated prefix and IA_NA address, and ULA enabled) might be configured. The corresponding data model is shown below the figure. Not all parameters are shown, and objects and parameters that the Controller is likely to have explicitly created or written are shown in bold face (some of these settings might alternatively be present in the factory default configuration).

Appendix VI: 6rd Theory of Operation

See Tunneling for general information on how tunneling is modeled.

VI.1 RFC 5969 Configuration Parameters

RFC 5969 [51] describes the general operation of the 6rd protocol and configuration of external parameters needed to do the protocol. Table 15 shows the 6rd configuration parameters defined in RFC 5969 and their mapping into the Device:2 data model. Refer to RFC 5969 for further description on use of these parameters.

Note that while RFC 5969 allows for multiple Border Relay (BR) IPv4 addresses, it does not describe how a device selects from among these. The device will need to have internal logic to handle this case, but service providers might wish to ensure that they know what the behavior will be, if they intend to supply multiple BR addresses.

VI.2 Internal Configuration Parameters

AddressSource, TunnelInterface, TunneledInterface, and AllTrafficToBorderRelay parameters are used to define internal device operation. AddressSource allows the desired source IPv4 address to be selected (to be embedded in the 6rd IPv6 address, after removing IPv4MaskLength bits from the beginning of the address, and as the source IPv4 address of the encapsulating IPv4 header). TunnelInterface and TunneledInterface allow for internal forwarding, routing, encapsulation, classification and marking of IPv6 packets. AllTrafficToBorderRelay impacts determination of the IPv4 destination address of the encapsulating IPv4 header.

VI.3 IPv4 Address Source

In general, it is expected that the device will use the IPv4 address obtained on the upstream interface as the address that is embedded in the 6rd IPv6 address, and used as the encapsulating source IPv4 address. However, there could be cases where the device has other public IPv4 addresses assigned to it, and it would be preferable to use one of these. For example, if the device has a public static IP address assigned to a different interface, it could be desired to use that address instead of the address assigned to the upstream interface.

If this parameter is not present, or if it is an empty string, the device will use internal logic to determine the source IPv4 address. In cases where there is a single upstream interface with an assigned (e.g., DHCPv4, IPCP, static) IPv4 address, that is the address that will be used.

Note that service providers need to be careful when using alternate addresses. If the alternate address does not have the same higher order IPv4 bits as other devices that will be supported by the same 6rd prefix, then the IPv4 mask will need to be zero. Masked IPv4 bits will be the same for all IPv4 addresses within a 6rd domain, per RFC 5969 [51].

VI.4 Sending All Traffic to the Border Relay Server

The default behavior of a 6rd client device is that all IPv6 packets are encapsulated in IPv4 packets with destination address of a 6rd border relay server, except when the IPv6 destination address begins with SPIPv6Prefix. When the destination IPv6 address begins with SPIPv6Prefix, then the encapsulating IPv4 destination address is derived from the IPv6 destination address by taking the next 32 - IPv4MaskLength bits, prepending the bits that are masked (as determined by its own WAN IPv4 address), and using the resulting IPv4 address as the encapsulating destination IPv4 address.

For example, if

• the IPv6 destination address is 2001:db8:64c8:200:x:x:x:x [note 64 hex = 100 decimal, c8 hex = 200 decimal, leading zeroes between colons are not shown]
• the SPIPv6Prefix is 2001:db8::/32
• the device’s WAN IPv4 address is 10.100.100.1
• IPv4MaskLength is 8
• advertised-to-LAN SLAAC prefix of 2001:db8:6464:100::/64

…then the encapsulation destination IPv4 address becomes the first 8 bits of the device’s WAN IPv4 address (10 for an address of 10.100.200.2), plus the next 24 bits (32-8=24) after the SPIPv6Prefix (next 24 bits are 64c802 hex = 100.200.2 binary). The source encapsulating IPv4 address is 10.100.100.1. The source IPv6 address begins with the prefix 2001:db8:6464:100::/64.

However, if AllTrafficToBorderRelay is True, then all external-bound IPv6 traffic is sent to the border relay.

This Boolean field is reflected in the routing table. If the value is False (default behavior), then the IPv6 routing table for this example (with a border relay IPv4 address of 10.0.0.1) would include the following entries:

If the AllTrafficToBorderRelay field is true, then the 2nd entry above does not exist.

VI.5 Internal Treatment of IPv6 Packets

Since a device can have multiple upstream and multiple downstream interfaces, the model supports a logical representation of the internal virtual 6rd IPv6 interface according to the general pattern described in Tunneling.

The internal virtual 6rd IPv6 interface is modeled as (TunnelInterface,TunneledInterface).

The IPv6Forwarding entries (which correspond to the routing table entries mentioned above) will route traffic between the downstream IPv6 interfaces and the 6rd IPv6 interface. IPv4Forwarding entries are unaffected.

Figure 45 shows the flow of tunneled 6rd traffic through the downstream, upstream, and the logical tunnel interfaces. Noted in the figure are sample values for the various IP.Interface entries that would be needed.

Appendix VII: Dual-Stack Lite Theory of Operation

See Tunneling for general information on how tunneling is modeled.

RFC 6333 [54] describes the general operation of the dual-stack lite (DS-Lite) technology and configuration of external parameters needed to do the protocol. RFC 6334 [55] defines an AFTR (Address Family Transition Router) name DHCPv6 option that maps to an EndpointName parameter in the Device:2 data model (introduced in Amendment 2).

EndpointName is a variable length field, containing a Fully Qualified Domain Name that refers to the AFTR the client is requested to establish a connection with. EndpointName can be assigned statically (e.g., present in the factory default configuration or set by the Controller) or dynamically (via DHCPv6). If both statically and dynamically assigned, then the EndpointAssignmentPrecedence parameter indicates whether it is the static configuration or the DHCPv6 configuration that is actually applied to EndpointName.

EndpointAddress is a 128 bit field, containing one IPv6 address. The tunnel EndpointAddress specifies the location of the remote tunnel endpoint, expected to be located at an AFTR. EndpointAddress can be assigned statically (e.g., present in the factory default configuration or set by the Controller) or dynamically (via DNS lookup when EndpointName is set). If both statically and dynamically assigned, then the EndpointAssignmentPrecedence parameter indicates whether it is the static configuration or the DHCPv6-derived configuration that is actually applied to EndpointAddress.

When EndpointName is assigned, the name is looked up (resolved) and the corresponding IPv6 address is set in EndpointAddress.

When DS-Lite is running in the device, the NAT function is disabled between the LAN and DSLite interface.

VII.1 Internal Treatment of IPv4 Packets

Since a device can have multiple upstream and multiple downstream interfaces, the model supports a logical representation of the internal virtual DS-Lite IPv4 interface according to the general pattern described in Tunneling.

The internal virtual DS-Lite IPv4 interface is modeled as (TunnelInterface,TunneledInterface).

The IPv4Forwarding entries will route traffic between the downstream IPv4 interfaces and the DS-Lite IPv4 interface. IPv6Forwarding entries are unaffected.

Figure 46 shows the flow of tunneled DS-Lite traffic through the downstream, upstream, and logical tunnel interfaces. Noted in the figure are sample values for the various IP.Interface entries that would be needed.

Appendix VIII: Advanced Firewall Example Configuration

The firewall rules modelled by Device.Firewall.Chain.{i}, Device.Firewall.DMZ.{i} and Device.Firewall.Pinhole.{i} operate only on the forwarding path. This means that they affect only routed traffic, and do not affect traffic that is destined for or generated by the device itself.

Traffic destined for or generated by the device itself SHOULD use the Device.Firewall.Service.{i} object to model the appropriate firewall rules.

Note that any NAT processing on the ingress packet occurs before firewall rules are applied so, for example, the firewall rules will see the translated destination IP address and port in a downstream packet that has passed through the NAT.

VIII.1 Config level

This section presents an advanced firewall example that illustrates settings corresponding to the following predefined Firewall.Config levels:

• High: The firewall implements the “Traffic Denied Inbound” and “Minimally Permit Common Services Outbound” components of the ICSA residential certification’s Required Services Security Policy [19]. If DoS and vulnerability protections are implemented [18], these are enabled.

• Low: All Outbound traffic and pinhole-defined Inbound traffic is allowed. If DoS and vulnerability protections are implemented [18], these are enabled.

    Firewall.
        Enable = true
        Config = "Advanced"
        AdvancedLevel = Firewall.Level.1
        Type = "Stateful"
    Firewall.Level.1.
        Name = "High"
        Description = "Deny Inbound and minimally permit Outbound"
        Order = 1
        Chain = Firewall.Chain.1
        DefaultPolicy = "Drop"
    Firewall.Level.2.
        Name = "Low"
        Description = "Allow all Outbound and pinhole-defined Inbound"
        Order = 2
        Chain = Firewall.Chain.2
        DefaultPolicy = "Drop"
    Firewall.Chain.1.
        Name = "High (Deny Inbound and minimally permit Outbound)"
        Creator = "Defaults"
        Rule.1.
            Order = 1
            Description = "Telnet"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 23
        Rule.2.
            Order = 2
            Description = "FTP"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 21
        Rule.3.
            Order = 3
            Description = "HTTP"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 80
        Rule.4.
            Order = 4
            Description = "HTTPS"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 443
        Rule.5.
            Order = 5
            Description= "SMTP"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 25
        Rule.6.
            Order = 6
            Description = "DNS"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 17                    # UDP
            DestPort = 53
        Rule.7.
            Order = 7
            Description = "POP3"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 110
        Rule.8.
            Order = 8
            Description = "IMAP"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
            Protocol = 6                     # TCP
            DestPort = 143
    Firewall.Chain.2.
        Name = "Low (Allow all Outbound and pinhole-defined Inbound)"
        Creator = "Defaults"
        Rule.1.
            Order = 1
            Description = "Outbound"
            Target = "Accept"
            DestInterface = IP.Interface.1   # upstream facing IP interface
        Rule.2.
            Order = 2
            Description = "Allow IPsec AH"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 6                    # IPv6
            Protocol = 51                    # AH
        Rule.3.
            Order = 3
            Description = "Allow IPsec ESP"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 6                    # IPv6
            Protocol = 50                    # ESP
        Rule.4.
            Order = 4
            Description = "Allow IPsec key exchange"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 6                    # IPv6
            Protocol = 17                    # UDP
            DestPort = 500
        Rule.5.
            Order = 5
            Description = "UPnP Port Mapping"
            Target = "TargetChain"
            TargetChain = Firewall.Chain.3
            SourceInterface = IP.Interface.1 # upstream facing IP interface
        Rule.6.
            Order = 6
            Description = "UPnP IPv6 Firewall"
            Target = "TargetChain"
            TargetChain = Firewall.Chain.4
            SourceInterface = IP.Interface.1 # upstream facing IP interface
        Rule.7.
            Order = 7
            Description = "User Interface"
            Target = "TargetChain"
            TargetChain = Firewall.Chain.5
            SourceInterface = IP.Interface.1 # upstream facing IP interface
    Firewall.Chain.3.
        Name = "UPnP Port Mapping (dynamic rules)"
        Creator = "PortMapping"
        Rule.1.
            Order = 1
            Description = "SSH"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 4                    # IPv4
            Protocol = 6                     # TCP
            DestPort = 22
    Firewall.Chain.4.
        Name = "UPnP IPv6 Firewall (dynamic rules)"
        Creator = "WANIPv6FirewallControl"
        Rule.1.
            Order = 1
            Description = "HTTP"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 6                    # IPv6
            Protocol = 6                     # TCP
            DestIP = 1080:0:0:800::1
            DestPort = 80
    Firewall.Chain.5.
        Name = "User Interface"
        Creator = "UserInterface"
        Rule.1.
            Order = 1
            Description = "SMTP server"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 4                    # IPv4
            Protocol = 6                     # TCP
            DestIP = 192.168.1.4
            DestPort = 25
        Rule.2.
            Order = 2
            Description = "DMZ"
            Target = "Accept"
            SourceInterface = IP.Interface.1 # upstream facing IP interface
            IPVersion = 4                    # IPv4
            DestIP = "192.168.1.5"           # IPv4 address of LAN device that recvs
                                             # all unsolicited inbound IPv4 traffic

VIII.2 Firewall policy

The firewall policy enables the definition of firewall rules for incoming and outgoing traffic. It defines the relation between source interface and destination interface and the reverse relation (between destination and source). In it simplest format it can be “Allow”/“Drop”, but in most cases it is useful to define a firewall chain target for both directions.

In a multi WAN, multi LAN environment, the policy concept can greatly reduce the complexity of the firewall configuration. It makes it easier to re-use firewall chains for different Interface configuration.

In order to configure more complex scenarios the firewall Levels are extended with a reference to the corresponding policy (instead of the Firewall.Chain.{i}. reference.).

The policy mode can be enabled by setting the firewall config parameter to Policy.

    Firewall.Config = Policy

VIII.2.1 Policy Level

The active firewall Level can be configured by referencing the Firewall.PolicyLevel parameter to one of the instantiated objects of the Firewall.Level.{i} table.

    Firewall.PolicyLevel = Firewall.Level.2

VIII.2.2 Policy referencing

Each firewall Level can have its own set of policies. Policies can be configured by referencing the Firewall.Level.{i}.Policies parameter to one or more of the instantiated objects of the Firewall.Policy.{i} table.

Below are some examples of the firewall level configuration corresponding with the firewall levels Low, Medium and High.

Firewall level Low

    Firewall.Level.1
      Alias = "Low"
      Name = "Low"
      Policies = Firewall.Policy.1,Firewall.Policy.2,Firewall.Policy.3,Firewall.Policy.4

Firewall level Medium

    Firewall.Level.2
      Alias = "Medium"
      Name = "Medium"
      Policies = Firewall.Policy.5,Firewall.Policy.6,Firewall.Policy.7,Firewall.Policy.8

Firewall level High

    Firewall.Level.2
      Alias = "High"
      Name = "High"
      Policies = Firewall.Policy.9,Firewall.Policy.10,Firewall.Policy.11,Firewall.Policy.12

VIII.2.3 Policy

The firewall policy specifies the firewall configuration between any two interfaces in a device. (Compared to the concept that a Level refers only to a single chain.) This implies that the interface configuration should no longer be specified in the Firewall.Chain.{i}.Rule.{i} but it should be inherited from the Firewall.Policy.{i} configuration.

Firewall policies Medium

    Firewall.Policy.5.
      Alias = "WAN2LAN"
      Enable = 1
      Status = "Enabled"
      TargetChain = "Chain"
      Chain= "Firewall.Chain.2"
      DestinationInterface = "Device.Logical.Interface.3."
      IPVersion = 0
      ReverseTargetChain = "Accept"
      ReverseChain = ""
      SourceInterface = "Device.Logical.Interface.1."
    Firewall.Policy.6.
      Alias = "WAN2GUEST"
      Enable = 1
      Status = "Enabled"
      TargetChain = "Chain"
      Chain = "Firewall.Chain.2"
      DestinationInterface = "Device.Logical.Interface.4."
      IPVersion = 0
      ReverseTargetChain = "Chain"
      ReverseChain = "Firewall.Chain.4."
      SourceInterface = "Device.Logical.Interface.1."
    Firewall.Policy.7.
      Alias="WAN2LCM"
      Enable = 1
      Status = "Enabled"
      TargetChain = "Chain"
      Chain = "Firewall.Chain.2"
      DestinationInterface = "Device.Logical.Interface.5."
      IPVersion = 0
      ReverseTargetChain = "Chain"
      ReverseChain = "Firewall.Chain.5."
      SourceInterface = "Device.Logical.Interface.1."
    Firewall.Policy.8.
      Alias = "LAN2LCM"
      Enable = 1
      Status = "Enabled"
      TargetChain = "Chain"
      Chain = "Firewall.Chain.2"
      DestinationInterface = "Device.Logical.Interface.5."
      IPVersion = 0
      ReverseTargetChain = "Chain"
      ReverseChain = "Firewall.Chain.5."
      SourceInterface = "Device.Logical.Interface.3."

As the default policy in the FORWARD chain is DROP, all FORWARD paths needs to be defined and explicitly opened if needed. A Policy is used to make this relation more clear, and allows the definition of rules for incoming and outgoing traffic.

The Chain parameter allows to reference a Firewall.Chain.{i} object where rules can be defined for traffic coming from the SourceInterface to the DestinationInterface, the ReverseChain parameter also allows you to provide a reference to a Firewall.Chain.{i} object where rules can be defined for traffic coming from the DestinationInterface to the SourceInterface.

When no rules are needed because traffic should simply be Accepted, Rejected or Dropped the TargetChain and ReverseTargetChain can be configured accordingly using the following options:

• Accept: The firewall forwards packets matching this rule.
• Reject: The firewall discards packets matching this rule, and sends an ICMP message to the originating host.
• Drop: The firewall discards packets matching this rule.
• Chain: The rules in the chain referenced by the ReverseChain parameter are matched.

Firewall chain Low

Firewall.Chain.1.
      Alias="L_Low"
      Creator="Defaults"
      Enable=1
      Name="L_Low"
      RuleNumberOfEntries=1
      Rule.1.
            Alias="cpe-Rule-1"
            CreationDate="2022-12-06T07:44:57.187868Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=1
            Protocol=-1
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0

Firewall chain Medium

Firewall.Chain.2.
      Alias = "L_Medium"
      Creator="Defaults"
      Enable=1
      Name="L_Medium"
      RuleNumberOfEntries=1
      Rule.1.
            Alias="cstate"
            CreationDate="2022-12-06T07:44:57.224803320Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=1
            Protocol=-1
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState="RELATED,ESTABLISHED"
            SourceMAC=""
            SourceMACExclude=0

Firewall chain High

Firewall.Chain.3.
      Alias="L_High"
      Creator="Defaults"
      Enable=1
      Name="L_High"
      RuleNumberOfEntries=13
      Rule.1.
            Alias="ftp-data"
            CreationDate="2022-12-06T07:44:57.279995140Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=20
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=1
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.10.
            Alias="imap"
            CreationDate="2022-12-06T07:44:57.487939660Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=143
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=10
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.11.
            Alias="https"
            CreationDate="2022-12-06T07:44:57.527839880Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=443
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=11
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.12.
            Alias="last-tcp-rule"
            CreationDate="2022-12-06T07:44:57.561464140Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=12
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Reject"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.13.
            Alias="last-rule"
            CreationDate="2022-12-06T07:44:57.600872040Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=13
            Protocol=-1
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Reject"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.2.
            Alias="ftp"
            CreationDate="2022-12-06T07:44:57.321648340Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=21
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=2
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.3.
            Alias="ssh"
            CreationDate="2022-12-06T07:44:57.341043640Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=22
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=3
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.4.
            Alias="smtp"
            CreationDate="2022-12-06T07:44:57.358718120Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=25
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=4
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.5.
            Alias="dns-udp"
            CreationDate="2022-12-06T07:44:57.376790140Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=5
            Protocol=17
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.6.
            Alias="dns-tcp"
            CreationDate="2022-12-06T07:44:57.391873460Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=6
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.7.
            Alias="http"
            CreationDate="2022-12-06T07:44:57.418379220Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=80
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=7
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.8.
            Alias="pop3"
            CreationDate="2022-12-06T07:44:57.432996420Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=110
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=8
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.9.
            Alias="ntp"
            CreationDate="2022-12-06T07:44:57.463105040Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=123
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=9
            Protocol=17
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0

Firewall chain Guest

Firewall.Chain.4.
      Alias="Guest"
      Creator="Defaults"
      Enable=1
      Name="Guest"
      RuleNumberOfEntries=5
      Rule.1.
      Rule.1.Alias="dns-udp"
            CreationDate="2022-12-06T07:44:57.663302800Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=1
            Protocol=17
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.2.
            Alias="dns-tcp"
            CreationDate="2022-12-06T07:44:57.698019980Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=2
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.3.
            Alias="http"
            CreationDate="2022-12-06T07:44:57.743905080Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=80
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=3
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.4.
            Alias="https"
            CreationDate="2022-12-06T07:44:57.784633700Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=443
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=4
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.5.
            Alias="icmp"
            CreationDate="2022-12-06T07:44:57.808069460Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=5
            Protocol=1
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0

Firewall chain LCM

Firewall.Chain.5.
      Alias="LCM"
      Creator="Defaults"
      Enable=1
      Name="LCM"
      RuleNumberOfEntries=5
      Rule.1.
            Alias="dns-udp"
            CreationDate="2022-12-06T07:44:57.848761260Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=1
            Protocol=17
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.2.
            Alias="dns-tcp"
            CreationDate="2022-12-06T07:44:57.885819Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=53
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=2
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.3.
            Alias="http"
            CreationDate="2022-12-06T07:44:57.903074620Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=80
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=3
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.4.
            Alias="https"
            CreationDate="2022-12-06T07:44:57.922807360Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=443
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=4
            Protocol=6
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0
      Rule.5.
            Alias="icmp"
            CreationDate="2022-12-06T07:44:57.955819140Z"
            DSCP=-1
            DSCPExclude=0
            Description=""
            DestAllInterfaces=1
            DestIP=""
            DestIPExclude=0
            DestInterface=""
            DestInterfaceExclude=0
            DestMask=""
            DestPort=-1
            DestPortExclude=0
            DestPortRangeMax=-1
            Enable=1
            ExpiryDate="9999-12-31T23:59:59Z"
            IPVersion=-1
            Log=0
            Order=5
            Protocol=1
            ProtocolExclude=0
            SourceAllInterfaces=1
            SourceIP=""
            SourceIPExclude=0
            SourceInterface=""
            SourceInterfaceExclude=0
            SourceMask=""
            SourcePort=-1
            SourcePortExclude=0
            SourcePortRangeMax=-1
            Status="Enabled"
            Target="Accept"
            TargetChain=""
            ConnectionState=""
            SourceMAC=""
            SourceMACExclude=0

VIII.2.4 Remarks

• The Firewall.Level.{i}.Chain parameter is no longer used.
• Firewall.Chain.{i}.Rule.{i} should not configure the:
  • SourceInterface
  • DestinationInterface
  • SourceInterfaceExclude
  • DestinationInterfaceExclude

as they might conflict with the Policy Interface configuration.

VIII.3 PriorityMap

The PriorityMap table defines which Priority value the device assigns to a new rule entry at creation time, based on the USP Controller that issued the create request.

When a Controller creates a new entry (for example, a NAT.PortMapping instance), the device looks up the applicable PriorityMap table by Controller reference. If a matching row is found, the Priority value from that row is written into the new entry as a read-only, auto-populated value. The TargetPaths parameter (a list) restricts which object types a row applies to.

There are two separate tables:

• Firewall.PriorityMap.{i}. — applies to Firewall.DMZ, Firewall.Pinhole, Firewall.Policy, and Firewall.Service entries.
• NAT.PriorityMap.{i}. — applies to NAT.PortMapping and NAT.PortTrigger entries.

The following example shows a NAT.PriorityMap configuration for two Controllers, applied to PortMapping entries only:

    NAT.PriorityMap.1.
        Controller  = "Device.LocalAgent.Controller.1."  # VPN App
        Priority    = 1000
        TargetPaths = "NAT.PortMapping"
    NAT.PriorityMap.2.
        Controller  = "Device.LocalAgent.Controller.2."  # Gaming App
        Priority    = 2000
        TargetPaths = "NAT.PortMapping"

When the VPN App creates a NAT.PortMapping entry, the device matches row 1 and auto-populates Priority = 1000. When the Gaming App creates one, the device matches row 2 and sets Priority = 2000.

Because Priority is evaluated in ascending order (lowest value first), the VPN App’s mappings are always evaluated before the Gaming App’s, regardless of which entry was created first.

VIII.4 DMZ example

A DMZ (De-Militarized Zone) entry forwards all unsolicited inbound traffic arriving on a WAN interface to a single designated host on the LAN, providing that host with unrestricted external reachability.

Firewall.DMZ.{i}. forwards all inbound traffic on an interface to a designated internal host (DestIP), optionally restricted to a source IPv4 prefix (SourcePrefix). An empty SourcePrefix acts as a wildcard that matches any source address. The DMZ engine evaluates entries in ascending Priority order and applies the first matching entry.

Priority and Controller are read-only parameters automatically populated by the device when the entry is created: Priority is derived from the Firewall.PriorityMap.{i}. table; Controller identifies the USP Controller that created the entry.

The following example forwards all inbound traffic from subnet 8.2.1.0/24 to a DMZ host:

    Firewall.DMZ.1.
        Alias        = "cpe-dmz-1"
        DestIP       = "192.168.1.50"
        Interface    = "Device.Logical.Interface.2."
        SourcePrefix = "8.2.1.0/24"
        Enable       = true

VIII.4.1 Priority and Firewall.DMZ

A wildcard DMZ entry (empty SourcePrefix) at a low Priority value will absorb all inbound traffic before any source-specific DMZ entry from another Controller can be reached. The following example shows two DMZ entries created by different Controllers, with Priority values auto-populated by the device:

    Firewall.DMZ.1.
        Description  = "Hosting App: catch-all to public server"
        Origin       = "Controller"
        Controller   = "Device.LocalAgent.Controller.1."  # read-only, auto-set
        Priority     = 1000                               # read-only, auto-set
        Interface    = "Device.IP.Interface.1."
        SourcePrefix = ""
        DestIP       = "192.168.1.100"
        Enable       = true
    Firewall.DMZ.2.
        Description  = "CDN App: traffic from CDN origin to cache server"
        Origin       = "Controller"
        Controller   = "Device.LocalAgent.Controller.2."  # read-only, auto-set
        Priority     = 2000                               # read-only, auto-set
        Interface    = "Device.IP.Interface.1."
        SourcePrefix = "203.0.113.0/24"
        DestIP       = "192.168.1.200"
        Enable       = true

Because DMZ.1 has an empty SourcePrefix (wildcard) and the lower Priority value, it is evaluated first. All inbound traffic — including traffic from the CDN origin subnet 203.0.113.0/24 — is forwarded to 192.168.1.100. DMZ.2 is never reached. To give the CDN App control over its traffic, its PriorityMap entry must assign it a lower Priority value than the Hosting App’s entry.

VIII.5 Pinhole example

A firewall pinhole opens a controlled inbound path through the firewall for a specific internal host, identified by destination IP and optionally restricted by port and protocol, without requiring NAT.

Firewall.Pinhole.{i}. allows inbound traffic to reach a specific internal host without NAT. Pinhole entries are evaluated in ascending Priority order and the first matching entry is applied. A value of -1 for DestPort, SourcePort, or Protocol acts as a wildcard that matches any value.

Priority and Controller are read-only parameters automatically populated by the device when the entry is created: Priority is derived from the Firewall.PriorityMap.{i}. table; Controller identifies the USP Controller that created the entry.

The following example creates a pinhole for an IP camera in the LAN:

    Firewall.Pinhole.1
      Alias = "cpe-pinhole-1"
      Description = "IP Camera"
      DestPort = "3343"
      Interface="Device.Logical.Interface.2."
      DestIP = "2002::10"
      Origin = "User"
      Protocol = "6,17"
      SourcePort = "3343"
      SourcePrefixes = ""
      Enable = 1

VIII.5.1 Priority and Firewall.Pinhole

A broad Pinhole with wildcard criteria at a low Priority value will intercept traffic before any narrower Pinhole entry from another Controller, even if that other entry would have been a more precise match.

Consider two Controllers that each open a Pinhole on the same interface, with Priority values auto-populated by the device:

    Firewall.Pinhole.1.
        Description = "Security App: allow all traffic to monitoring host"
        Origin      = "Controller"
        Controller  = "Device.LocalAgent.Controller.1."  # read-only, auto-set
        Priority    = 1000                               # read-only, auto-set
        Interface   = "Device.IP.Interface.1."
        DestIP      = "192.168.1.10"
        DestPort    = -1
        Protocol    = [-1]
        Enable      = true
    Firewall.Pinhole.2.
        Description = "VoIP App: allow SIP signalling to VoIP adapter"
        Origin      = "Controller"
        Controller  = "Device.LocalAgent.Controller.2."  # read-only, auto-set
        Priority    = 2000                               # read-only, auto-set
        Interface   = "Device.IP.Interface.1."
        DestIP      = "192.168.1.20"
        DestPort    = 5060
        Protocol    = [17]
        Enable      = true

Pinhole.1 opens all traffic to 192.168.1.10 and has the lower Priority value, so it is evaluated first. Any inbound packet arriving on Device.IP.Interface.1. destined for 192.168.1.10 matches Pinhole.1 and is allowed through. Pinhole.2 restricts traffic to UDP port 5060 destined for 192.168.1.20 and is only reached if the packet did not match Pinhole.1.

If the Security App’s Controller should not take precedence over VoIP signalling traffic, its PriorityMap entry must assign it a higher Priority value than the VoIP App’s entry.

VIII.6 Service example

A firewall service rule controls access to services running on the device itself — for example, restricting which interfaces or source addresses may reach the device’s management plane, DNS resolver, or other locally hosted services.

Firewall.Service.{i}. controls access to services running on the device itself (as opposed to traffic forwarded to internal hosts). Each entry specifies an Interface, a list of destination ports (DestPort), a list of protocols (Protocol), and an Action (Accept, Drop, or Reject). The Service engine evaluates entries in ascending Priority order and applies the Action of the first matching entry.

Priority and Controller are read-only parameters automatically populated by the device when the entry is created: Priority is derived from the Firewall.PriorityMap.{i}. table; Controller identifies the USP Controller that created the entry.

The following example opens a local port for the DNS service provided by the device:

    Firewall.Service.1
      Action = "Accept"
      Alias = "dns-Logical-3"
      DestinationPort = "53"
      ICMPType = -1
      IPVersion = 0
      Interface = "Device.Logical.Interface.3."
      Protocol = "6,17"
      SourcePrefix = ""
      Enable = 1

VIII.6.1 Priority and Firewall.Service

Because Service entries carry an explicit Action, the evaluation order directly determines whether traffic is accepted or blocked. A blocking rule at a low Priority value will suppress all matching traffic before any accepting rule from another Controller is reached, and vice versa.

The following example shows two Controllers each creating a Service rule for the same management interface and port, with Priority values auto-populated by the device:

    Firewall.Service.1.
        Description = "Mgmt App: block management from untrusted segment"
        Origin      = "Controller"
        Controller  = "Device.LocalAgent.Controller.1."  # read-only, auto-set
        Priority    = 1000                               # read-only, auto-set
        Interface   = "Device.IP.Interface.1."
        DestPort    = [830]
        Protocol    = [6]
        Action      = "Drop"
        Enable      = true
    Firewall.Service.2.
        Description = "Ops App: allow NETCONF from operations team"
        Origin      = "Controller"
        Controller  = "Device.LocalAgent.Controller.2."  # read-only, auto-set
        Priority    = 2000                               # read-only, auto-set
        Interface   = "Device.IP.Interface.1."
        DestPort    = [830]
        Protocol    = [6]
        Action      = "Accept"
        Enable      = true

Service.1 has the lower Priority value and drops all TCP traffic to port 830 (NETCONF). It is evaluated before Service.2, so the Ops App’s Accept rule is never reached — all NETCONF traffic on this interface is dropped regardless of source. To allow the Ops App to accept NETCONF traffic, its PriorityMap entry must assign it a lower Priority value than the management blocking rule.

VIII.7 PortMapping example

Static port forwarding maps an external port (or port range) on the WAN interface to a specific internal host and port on the LAN, making a LAN-side service reachable from the internet.

NAT.PortMapping.{i}. models static port forwarding rules. Each entry maps an external port (or range of ports) on the WAN interface to an internal host and port on the LAN. When an inbound packet arrives on the WAN interface, the NAT engine walks the PortMapping table in ascending Priority order and applies the first entry whose criteria match the packet.

The key match criteria are:

• Protocol — TCP or UDP.
• ExternalPort / ExternalPortEndRange — the WAN-side port or port range. A value of zero is a wildcard that matches any port not claimed by a more specific entry (within the same Priority level).
• RemoteHost — the source IP address on the WAN side. An empty string is a wildcard that matches any remote host (within the same Priority level).

The following example forwards inbound TCP traffic on WAN port 8443 from any remote host to an internal HTTPS server:

    NAT.PortMapping.1.
        Alias          = "cpe-pm-https"
        Description    = "HTTPS server"
        Origin         = "User"
        Enable         = 1
        Protocol       = "TCP"
        ExternalPort   = 8443
        RemoteHost     = ""
        InternalClient = "192.168.1.100"
        InternalPort   = 443

A second entry forwards all other inbound TCP traffic from a specific remote management host to a jump server, using a wildcard external port:

    NAT.PortMapping.2.
        Alias          = "cpe-pm-mgmt"
        Description    = "Remote management jump server"
        Origin         = "User"
        Enable         = 1
        Protocol       = "TCP"
        ExternalPort   = 0
        RemoteHost     = "203.0.113.1"
        InternalClient = "192.168.1.200"
        InternalPort   = 22

Because PortMapping.1 has an explicit ExternalPort and PortMapping.2 has a wildcard (ExternalPort = 0), a TCP packet from 203.0.113.1 on port 8443 matches both entries. Within the same Priority level the explicit-port entry takes precedence, so the packet is forwarded to the HTTPS server at 192.168.1.100:443. All other TCP traffic from 203.0.113.1 on any port is forwarded to the jump server at 192.168.1.200:22.

Because Protocol accepts only a single value per entry, forwarding both TCP and UDP on the same external port requires two separate PortMapping entries. The following example forwards a game server that uses both TCP and UDP on the same port:

    NAT.PortMapping.3.
        Alias          = "cpe-pm-game-tcp"
        Description    = "Game server (TCP)"
        Origin         = "User"
        Enable         = 1
        Protocol       = "TCP"
        ExternalPort   = 27015
        RemoteHost     = ""
        InternalClient = "192.168.1.50"
        InternalPort   = 27015
    NAT.PortMapping.4.
        Alias          = "cpe-pm-game-udp"
        Description    = "Game server (UDP)"
        Origin         = "User"
        Enable         = 1
        Protocol       = "UDP"
        ExternalPort   = 27015
        RemoteHost     = ""
        InternalClient = "192.168.1.50"
        InternalPort   = 27015

VIII.7.1 Controller priority example

When multiple independent Controllers create firewall rules, the Priority and Controller parameters determine evaluation precedence.

The Firewall.PriorityMap.{i}. table is configured by the device to define the Priority value each new firewall entry receives. When a Controller creates a new firewall entry, the USP device looks up this table by Controller reference and auto-populates the Priority parameter accordingly.

PriorityMap configuration (set by the device)

    Firewall.PriorityMap.1.
        Controller  = "Device.LocalAgent.Controller.1."  # Security App
        Priority    = 1000
        TargetPaths = "Firewall.Policy,Firewall.Pinhole"
    Firewall.PriorityMap.2.
        Controller  = "Device.LocalAgent.Controller.2."  # Gaming App
        Priority    = 2000
        TargetPaths = "Firewall.Policy,Firewall.Pinhole"

Resulting firewall entries

    Firewall.Pinhole.1.
        Description = "Security App: remote monitoring"
        Origin      = "Controller"
        Priority    = 1000
        Controller  = "Device.LocalAgent.Controller.1."
        DestPort    = "443"
        Protocol    = "6"
        Enable      = 1
    Firewall.Pinhole.2.
        Description = "Gaming App: game server"
        Origin      = "Controller"
        Priority    = 2000
        Controller  = "Device.LocalAgent.Controller.2."
        DestPort    = "27015"
        Protocol    = "17"
        Enable      = 1
    Firewall.Pinhole.3.
        Description = "User: IP camera"
        Origin      = "User"
        Priority    = 10000
        Controller  = ""
        DestPort    = "3343"
        Protocol    = "6,17"
        Enable      = 1

Rules are evaluated in ascending Priority value: Pinhole.1 (Priority 1000) is evaluated first, Pinhole.3 (Priority 10000) last. The Controller parameter enforces access control: only Device.LocalAgent.Controller.1. can modify or delete Pinhole.1; Device.LocalAgent.Controller.2. can modify or delete Pinhole.2.

VIII.7.2 Priority and NAT.PortMapping wildcard precedence

NAT.PortMapping.{i}. has built-in precedence rules that apply whenever wildcard values are used for RemoteHost and/or ExternalPort. When multiple entries match the same incoming packet, these rules determine which mapping is applied (from highest to lowest precedence):

1. Explicit RemoteHost, explicit ExternalPort
2. Explicit RemoteHost, zero ExternalPort
3. Empty RemoteHost, explicit ExternalPort
4. Empty RemoteHost, zero ExternalPort

When Priority is also present, it takes effect before the wildcard-specificity rules. The NAT engine evaluates entries in ascending Priority order and applies the first matching entry, regardless of how specific its RemoteHost and ExternalPort values are. The wildcard-specificity rules only apply as a tiebreaker between entries that share the same Priority value.

This means that a Controller assigning a low Priority value to a broad (wildcard) mapping will cause that mapping to take effect before any higher-Priority entry, even if the higher-Priority entry would have been a more specific match. It is therefore the responsibility of the system — through the NAT.PriorityMap.{i}. table — to assign Priority values that reflect the intended evaluation order, taking specificity into account.

Consider the following scenario where two Controllers have each created a PortMapping entry:

    NAT.PortMapping.1.
        Description    = "VPN App: catch-all redirect"
        Origin         = "Controller"
        Priority       = 1000
        Controller     = "Device.LocalAgent.Controller.1."
        RemoteHost     = ""        # wildcard
        ExternalPort   = 0         # wildcard
        Protocol       = "TCP"
        InternalClient = "192.168.1.10"
        InternalPort   = 1194
        Enable         = 1
    NAT.PortMapping.2.
        Description    = "Gaming App: specific host and port"
        Origin         = "Controller"
        Priority       = 2000
        Controller     = "Device.LocalAgent.Controller.2."
        RemoteHost     = "203.0.113.5"
        ExternalPort   = 27015
        Protocol       = "TCP"
        InternalClient = "192.168.1.20"
        InternalPort   = 27015
        Enable         = 1

For an incoming TCP packet from 203.0.113.5 on port 27015, both entries match. Because PortMapping.1 has the lower Priority value (1000 < 2000), it is evaluated first and its mapping is applied — the packet is forwarded to 192.168.1.10:1194. PortMapping.2 is never reached, even though its RemoteHost and ExternalPort would have been an exact match.

The VPN App’s Controller therefore holds effective priority over all TCP traffic, regardless of which other Controllers have created more specific rules. To give the Gaming App control over traffic from 203.0.113.5:27015, its PriorityMap entry would need to assign it a lower Priority value than the VPN App’s entry.

VIII.8 PortTrigger example

Port triggering opens inbound ports automatically and temporarily whenever a LAN host initiates outbound traffic on a designated trigger port, without requiring a static mapping to a fixed internal host.

NAT.PortTrigger.{i}. implements dynamic port forwarding. When the device detects outbound traffic from a LAN host on the trigger Port (or port range), it automatically opens the inbound ports defined in the entry’s Rule table for that host for the duration of AutoDisableDuration. The Protocol parameter (single value: TCP or UDP) specifies the protocol of the trigger traffic.

Priority and Controller are read-only parameters automatically populated by the device when the entry is created: Priority is derived from the NAT.PriorityMap.{i}. table; Controller identifies the USP Controller that created the entry.

The following example opens inbound UDP ports 3074–3075 when a LAN host sends outbound UDP traffic on port 3074 (a common pattern for game consoles):

    NAT.PortTrigger.1.
        Alias               = "cpe-pt-game"
        Description         = "Game console: open lobby ports"
        Origin              = "User"
        Enable              = true
        Interface           = "Device.IP.Interface.2."
        Port                = 3074
        PortEndRange        = 0
        Protocol            = "UDP"
        AutoDisableDuration = 300
        Rule.1.Port         = 3074
        Rule.1.PortEndRange = 3075
        Rule.1.Protocol     = "UDP"

VIII.8.1 Priority and NAT.PortTrigger

The PortTrigger engine evaluates entries in ascending Priority order. When outbound traffic matches the trigger criteria of the first matching entry, that entry’s inbound rules are activated. Entries with higher Priority values (lower precedence) are only reached if no lower-Priority entry matched.

When multiple Controllers each create a PortTrigger entry that watches the same trigger port, the entry with the lower Priority value determines which set of inbound ports is opened for the triggering host:

    NAT.PortTrigger.1.
        Description         = "Gaming App: open game lobby ports on UDP trigger"
        Origin              = "Controller"
        Controller          = "Device.LocalAgent.Controller.1."  # read-only
        Priority            = 1000                               # read-only
        Interface           = "Device.IP.Interface.2."
        Port                = 3074
        PortEndRange        = 0
        Protocol            = "UDP"
        Enable              = true
        Rule.1.Port         = 3074
        Rule.1.PortEndRange = 3075
        Rule.1.Protocol     = "UDP"
    NAT.PortTrigger.2.
        Description         = "VPN App: open IPsec ports on UDP trigger"
        Origin              = "Controller"
        Controller          = "Device.LocalAgent.Controller.2."  # read-only
        Priority            = 2000                               # read-only
        Interface           = "Device.IP.Interface.2."
        Port                = 3074
        PortEndRange        = 0
        Protocol            = "UDP"
        Enable              = true
        Rule.1.Port         = 500
        Rule.1.PortEndRange = 0
        Rule.1.Protocol     = "UDP"

Both entries watch for outbound UDP traffic on port 3074. Because PortTrigger.1 has the lower Priority value, it is evaluated first: when a LAN host sends UDP traffic on port 3074, the Gaming App’s rule fires and opens inbound UDP ports 3074–3075. PortTrigger.2 is never evaluated for this trigger event, so the VPN App’s IPsec ports (UDP 500) are not opened.

If the VPN App’s port trigger must take precedence, its PriorityMap entry must assign it a lower Priority value than the Gaming App’s entry.

VIII.9 Firewall logging

Firewalls monitor network traffic and enforce security policies. To aid in debugging and troubleshooting potential issues, it’s possible to capture specific information when certain rules are triggered. These captured details, known as traces, are then written to the kernel log for further analysis.

      [ 1605.521070] Service:IN=eth1 OUT=
        MAC=ac:91:9b:3a:5d:0c:ba:97:fc:3e:8b:fa:86:dd SRC=fe80:0000:0000:0000:b897:fcff:fe3e:8bfa
        DST=fe80:0000:0000:0000:ae91:9bff:fe3a:5d0c
        LEN=200
        TC=0
        HOPLIMIT=64
        FLOWLBL=343962
        PROTO=UDP
        SPT=547
        DPT=546
        LEN=160

VIII.9.1 Logging control in firewall rules

In modern operating systems firewall rules can be configured to generate log entries when triggered. This section details the mechanism that controls logging behaviour:

1. Log table: Each type of firewall rule (Chain Rule, Service Rule, etc.) can have one or more Firewall.Log.{i}. instances associated. These objects contain configuration options and an Enable parameter.
2. Firewall rule: Each firewall rule also possesses its own “Log” enable parameter that controls if a firewall rule needs to generate a log message or not.

VIII.9.2 Enabling firewall logging

For a Firewall.Log.{i}. entry to take effect, both of these settings must be true:

1. Firewall.Log.{i}.Enable: The Enable parameter for the specific log instance.
2. Firewall.Chain.{i}.Rule.{i}.Log: The Log parameter for the specific rule instance.

VIII.9.3 Log filtering

The Firewall.Log table describes additional filtering and logging policies, that can dynamically add or remove firewall logging statements to and from the operating system.

• Firewall.Log.{i}.Filter.Policy: When set to Denied, logs are only generated for rules with a Drop or Reject target. Logs are included regardless of the target when set to All.
• Firewall.Log.{i}.Filter.SourceInterface: Matches the source interface specified in the firewall rule (e.g. Firewall.Chain.{i}.Rule.{i}.SourceInterface). An empty string means that the source interface will be ignored from a filtering perspective.
• Firewall.Log.{i}.Filter.DestinationInterface: Similar to Firewall.Log.{i}.Filter.SourceInterface but filters based on the firewall rule’s destination interface (e.g. Firewall.Chain.{i}.Rule.{i}.DestinationInterface).

Example: Firewall Service instance 22 (Alias: “cpe-httpaccess-Device-IP-Interface-2-v4-8090”) is enabled and accepts IPv4 TCP traffic on port 8090 of interface Device.IP.Interface.2. Logging is enabled for this service and is configured to use log table instance 2 (Alias: “cpe-logrule1”) as additional logging criteria.

      Firewall.Service.22.
      Firewall.Service.22.Action="Accept"
      Firewall.Service.22.Alias="cpe-httpaccess-Device-IP-Interface-2-v4-8090"
      Firewall.Service.22.DestPort="8090"
      Firewall.Service.22.Enable=1
      Firewall.Service.22.ICMPType=-1
      Firewall.Service.22.IPVersion=4
      Firewall.Service.22.Interface="Device.IP.Interface.2"
      Firewall.Service.22.Protocol="6"
      Firewall.Service.22.SourcePrefixes=""
      Firewall.Service.22.Status="Enabled"
      Firewall.Service.22.Log=1
      Firewall.Service.22.LogRef="Firewall.Log.2"

Log table instance 2 (Alias: “cpe-logrule1”) is enabled and logs all allowed traffic originating from interface Device.IP.Interface.2 with no destination interface restrictions. Log messages are prefixed with “Rule” and have a severity level of “Debug”.

      Firewall.Log.2.Alias="cpe-logrule1"
      Firewall.Log.2.Description="Logs all allowed from interface IP.Interface.2"
      Firewall.Log.2.Enable=1
      Firewall.Log.2.Filter.DestinationInterface=""
      Firewall.Log.2.Filter.Policy="Allowed"
      Firewall.Log.2.Filter.SourceInterface="Device.IP.Interface.2"
      Firewall.Log.2.Severity="Debug"
      Firewall.Log.2.Prefix="Rule"

VIII.9.4 Policy Filtering

Firewall log statements are added to the operating system only when the Policy parameter in the Log table matches the policy specified by the firewall rule.

The specific parameter used to represent the firewall policy depends on the firewall concept being configured (e.g., PortMapping, PortTrigger, Policy, Pinhole, DMZ, Service). While this parameter might not always be explicitly defined in the data model, its value is determined by the system’s implementation.

For example, firewall rules for PortMapping, PortTrigger, Pinhole and DMZ concepts typically have an implicit “Allow” policy.

VIII.9.4.1 Firewall Service rules

For firewall Service rules, the policy is determined by the Firewall.Service.{i}.Action parameter.

VIII.9.4.2 Firewall Policy rules

For firewall Policy rules, the policy is determined by either Firewall.Policy.{i}.TargetChain or Firewall.Policy.{i}.ReverseTargetChain, depending on the specified SourceInterface and DestinationInterface.

VIII.9.4.3 Firewall Chain rules

For firewall chain rules, the policy is determined by the Firewall.Chain.{i}.Rule.{i}.Target parameter.

VIII.9.5 Interface Filtering

Firewall log statements are added to the operating system only when the SourceInterface and/or DestinationInterface parameters in the Log table match the interface parameters specified by the INTERNAL firewall rule.

The specific interface parameters used for matching depend on the firewall concept being configured (e.g., PortMapping, PortTrigger, Policy, Pinhole, DMZ, Service). While these parameters might not always be explicitly defined in the data model, their values are determined by the system’s implementation.

Note: The following descriptions provide typical matching patterns. Actual implementations may vary.

VIII.9.5.1 NAT PortMapping rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.NAT.PortMapping.{i}.Interface (usually the WAN interface).
• Firewall.Log.{i}.Filter.DestinationInterface typically matches the interface where Device.NAT.PortMapping.{i}.InternalClient resides.

VIII.9.5.2 NAT PortTrigger rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches the LAN interface.
• Firewall.Log.{i}.Filter.DestinationInterface typically matches the WAN interface.

VIII.9.5.3 Firewall Policy rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.Firewall.Policy.{i}.SourceInterface.
• Firewall.Log.{i}.Filter.DestinationInterface typically matches Device.Firewall.Policy.{i}.DestinationInterface.

VIII.9.5.4 Firewall Chain rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.Firewall.Chain.{i}.Rule.{i}.SourceInterface.
• Firewall.Log.{i}.Filter.DestinationInterface typically matches Device.Firewall.Chain.{i}.Rule.{i}.DestinationInterface.

VIII.9.5.5 Firewall Pinhole rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.Firewall.Pinhole.{i}.Interface (usually the WAN interface).
• Firewall.Log.{i}.Filter.DestinationInterface typically matches the interface where Device.Firewall.Pinhole.{i}.DestIP resides.

VIII.9.5.6 Firewall DMZ rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.Firewall.DMZ.{i}.Interface (usually the WAN interface).
• Firewall.Log.{i}.Filter.DestinationInterface typically matches the interface where Device.Firewall.DMZ.{i}.DestIP resides.

VIII.9.5.7 Firewall Service rules

• Firewall.Log.{i}.Filter.SourceInterface typically matches Device.Firewall.Service.{i}.Interface (usually the LAN interface).
• Firewall.Log.{i}.Filter.DestinationInterface typically matches the LAN interface.

VIII.9.6 Multiple log table reference

A firewall rule can reference one or more Firewall.Log.{i}. instances.

      Firewall.Chain.1.Rule.1.LogRef="Firewall.Log.2, Firewall.Log.3"

The firewall log statements will be activated when either or both Log table references are enabled and when the Log parameter on the firewall rule is enabled.

Example: Firewall.Chain.1.Rule.1.Log AND ( Firewall.Log.2.Enable OR Firewall.Log.3.Enable) MUST be true.

Syslog level When both Log table references are active and all the filter policies match, the Syslog severity that will be used is determined by the Severity parameter. This severity will be the lower of the two severities specified in Firewall.Log.2 and Firewall.Log.3.

Possible Syslog severity levels: 0. Emergency (Indicates that the system is unusable) 1. Alert (Indicating that an action must be taken immediately) 2. Critical (Indicates a critical condition) 3. Error (Indicates an error condition) 4. Warning (Indicates a warning condition) 5. Notice (Indicates a normal but important message) 6. Informational (Indicates an information message) 7. Debug (Indicates a debug-level message)

      Firewall.Log.2.Enable=1
      Firewall.Log.2.Severity="Warning"
      ...
      Firewall.Log.3.Enable=1
      Firewall.Log.3.Severity="Debug"
      ...

In the above example the Syslog severity defined in instance Log.2 is lower than the Syslog severity specified in instance Log.3 therefore the Syslog severity used for logging is ‘’Warning’’.

Firewall prefix

When both Log table references are active, the prefixes can be aggregated.

      Firewall.Log.2.Enable=1
      Firewall.Log.2.Prefix="Rule2"
      ...
      Firewall.Log.3.Enable=1
      Firewall.Log.3.Prefix="Rule3"
      ...

Aggregation example:

      "[FW][Rule2,Rule3]:"...

Appendix IX: IPsec Theory of Operation

See Tunneling for general information on how tunneling is modeled.

The Device:2 data model includes an IPsec (RFC 4301 [41]) object that supports the configuration of Encapsulating Security Payload (ESP; RFC 4303 [43]) and Authentication Header (AH; RFC 4302 [42]) in tunnel mode (Section 3.2/RFC 4301). Use of IKEv2 (RFC 5996 [52]) is assumed. The IPsec object does not currently support static configuration of tunnels and child Security Associations (SAs).

Figure 51 illustrates the main IPsec objects and their relationships.

In the Figure, instances of the colored objects (Filter.{i} and Profile.{i}) are created and populated by the Controller. Instances of all other objects are handled by the device as IPsec tunnels are created and deleted. References between objects are shown:

• Solid lines indicate references that are populated by the Controller, and dashed lines indicate references that are handled by the device.
• A reference marked “(U)” is a unique key, which implies a 1-1 relationship, e.g., only one Tunnel instance can reference a given (Tunnel,Tunneled) IP.Interface pair.
• Other references imply n-1 relationships, e.g., multiple Filter instances can reference a given Profile instance.

Typical usage is as follows:

• The factory default configuration can contain static instances of the various objects.
• The Controller creates and configures Filter and Profile instances. Filter instances model IPsec Security Policy Database (SPD) selection criteria and Profile instances model SPD processing info. Each Filter instance references a Profile instance so a single Profile instance can, if desired, be shared by several Filter instances.
• When the Controller enables a Filter instance, the device determines whether a new tunnel is needed in order to carry the traffic that matches that filter. It is possible that an existing tunnel can carry the traffic.
• If a new tunnel is needed, the device immediately creates a Tunnel instance that references a newly-created (Tunnel,Tunneled) IP Interface pair. This corresponds exactly to the general tunneling approach that is described in Tunneling.
• Each Tunnel instance also references all of the currently-enabled Filter instances that require it to exist.
• Classification and forwarding rules can now be defined, regardless of whether the tunnels have yet been established. ForwardingPolicy is both a QoS Classification result and an IPsec Filter result (it’s in the Policy table), and so can, as explained in Tunneling, affect the forwarding decision and thus whether or not a given packet will be en-tunneled or de-tunneled.
• When a tunnel needs to become active, e.g., as a result of traffic that matches one of the Filter instances, the device will establish it and will create the appropriate IKEv2SA and ChildSA objects.
• When a tunnel no longer needs to be active, the device will delete the ChildSA and IKEv2SA objects. This will affect the status of the Tunnel instance and (Tunnel,Tunneled) IP Interface pair but will not delete them.

The remainder of this Appendix consists of a brief summary of the various IPsec data model objects.

IX.1 IPsec

The top-level object has an Enable parameter that enables and disables the IPsec sub-system, various capability parameters, e.g., supported encryption algorithms, and global IPsec statistics.

IX.2 IPsec.Filter

The Filter table models IPsec Security Policy Database (SPD) selection criteria. Refer to Section 4.4.1/RFC 4301 [41] for further details.

SPD filtering is performed for all packets that might need to cross the IPsec boundary. Refer to Section 3.1/RFC4301 for further details. Given that IPsec operates at the IP level, this means that SPD filtering conceptually occurs after bridging and before routing.

This table is conceptually quite similar to the QoS Classification table in that entries are ordered, associated with an ingress interface, include selection criteria, and specify the action to be taken for matching packets.

Instances of the Filter table can be created statically by the device, or can be created and deleted by the Controller as needed. Each instance includes the following (this is not a complete list):

• Enable: to enable and disable the entry.
• Status: to indicate the status of the entry.
• Order: to control and indicate the order of the entry.
• Interface, AllInterfaces: to control and indicate with which interfaces the entry is associated.
• DestIP: to select packets by destination IP address.
• SourceIP: to select packets by source IP address.
• Protocol: to select packets by IP protocol.
• DestPort: to select packets by destination port.
• SourcePort: to select packets by source port.
• Discard: whether to discard matching packets.
• Profile: the Profile instance that governs how non-discarded matching packets will be treated.

IX.3 IPsec.Profile

The Profile table models IPsec Security Policy Database (SPD) processing info. Refer to Section 4.4.1/RFC 4301 [41] for further details. Each Filter instance references a Profile instance. It would be possible to include the processing info directly in each Filter instance, but use of a separate table allows Profile entries to be shared between Filter instances.

Instances of the Profile table can be created statically by the device, or can be created and deleted by the Controller as needed. Each instance includes the following (this is not a complete list):

• MaxChildSAs: the maximum number of Child SAs per IKEv2 session (and therefore per IPsec tunnel); this provides a simple way of controlling the extent to which existing tunnels can be re-used.
• RemoteEndpoints: an ordered list of remote tunnel endpoints that are to be used when establishing an IPsec tunnel corresponding to this Profile instance.
• ForwardingPolicy: an opaque (Controller-chosen) value that provides a feed-forward mechanism that allows the SPD filtering decision to affect the forwarding decision. QoS classification uses the same mechanism.
• Protocol: the “child” security protocol, i.e., AH or ESP.
• IKEv2AuthenticationMethod: a reference to a device certificate or other device credentials.
• IKEv2AllowedEncryptionAlgorithms (etc): encryption algorithm that IKEv2 is permitted to negotiate; also several other “allowed” parameters that define acceptable IKEv2, AH and ESP algorithms.
• DSCPMarkPolicy (etc): various settings that govern how packets should be tunneled.

IX.4 IPsec.Tunnel

The Tunnel table that models IPsec tunnels. Instances are created and deleted by the device as needed. A (Tunnel,Tunneled) IP Interface pair is always created at the same time as an IPsec Tunnel instance and has the same lifetime; the Tunnel IP Interface contains generic IP interface settings, e.g., Enable, Status and generic Stats, and the IPSec Tunnel instance contains IPsec-specific settings, e.g., additional Stats.

IX.5 IPsec.IKEv2SA

Each entry in the IKEv2SA table models a single IKEv2 SA pair and uniquely references a Tunnel instance. Unlike Tunnel instances, which exist regardless of whether the tunnel is active, IKEv2SA instances exist only when the IKEv2 SA pair exists, i.e., they exist only when the tunnel is active.

IX.6 IPsec.IKEv2SA.ChildSA

The ChildSA table models child SA pairs. It is a child of the corresponding IKEv2SA instance and so exists only when the IKEv2SA instance exists.

Appendix X: ETSI M2M Remote Entity Management Theory of Operation

Figure 52 below depicts the high level ETSI M2M functional architecture defined in section 4 of ETSI TS 102 690 [15]. The Data Models defined [16] are used within CWMP enabled Devices and Gateways within the Device and Gateway domain.

Within the Device and Gateway Domain, the M2M Device and Gateway contains 2 functional components as defined in the ETSI M2M Functional Architecture [15]:

• M2M Service Capabilities: M2M functions that are to be shared by different M2M Applications.
• M2M Applications: Applications that run the service logic and use M2M Service Capabilities.

Interactions between components within the ETSI architecture are defined using reference points. Figure 53 below illustrates the Service Capability Layer (SCL) mId reference point that is of interest. A full explanation of the SCL reference points is provided in section 5 of the ETSI M2M Functional Architecture [15].

The M2M Device or Gateway SCL provides capabilities (functionality) for the following areas:

• Application Enablement (xAE)
• Generic Communication (xGC)
• Reachability, Addressing and Repository (xRAR)
• Communication Selection (xCS)
• Remote Entity Management (xREM)
• SECurity (xSEC)
• History and Data Retention (xHDR)
• Transaction Management (xTM)
• Compensation Broker (xCB)
• Telco Operator Exposure (xTOE)
• Interworking Proxy (xIP)

The Data Model in [16] reflects the device management objects and parameters necessary to implement xREM functionality across the mId reference point as defined in Annex E of the ETSI Functional Architecture [15] is depicted in Figure 54. In this instance, the Device Mgmt Client is considered a CWMP endpoint interface and the Device Mgmt Server is considered the ACS interface. In most situations, these endpoints and servers have an interface between the native Device, Gateway or Server environment and the SCL. In addition, the dIa reference point, using RESTful procedures, is used to discover M2M D’ Devices and M2M Applications as well as proxy selected xREM management functions.

Within the ETSI M2M Functional Architecture, the xREM is responsible for the following management functions:

• General Management: Provides retrieval of information related to the M2M Device or Gateway that hosts the ETSI M2M Service Capability Layer (SCL).
• Configuration Management: Provides configuration of the M2M Device or Gateway’s capabilities in order to support ETSI M2M Services and Applications.
• Diagnostics and Monitoring Management: Provides diagnostic tests and retrieves/receives alerts associated with the M2M Device or Gateway that hosts the SCL.
• Software Management: Maintains software associated with the SCL and M2M services.
• Firmware Management: Maintain firmware associated with the M2M Device or Gateway that hosts the SCL.
• Area Network Management: Maintains devices on the M2M Area Network associated with the SCL.
• SCL Administration: Provides administration capabilities in order to configure and maintain a SCL within the M2M Device or Gateway.

Within the customer premises, equipment is categorized within the ETSI M2M framework as a:

• M2M Gateway: A Gateway that runs M2M Application(s) using M2M Service Capabilities.
• M2M Device: A Device that runs applications using M2M capabilities and network domain functions. Depending on M2M capabilities of the M2M Device, the M2M Device is defined as a:
  • Device (D): provides M2M Service Capabilities (DSCL) that communicates to an NSCL using the mId reference point and to DA using the dIa reference point
  • Device’ (D’): hosts a Device Application (DA) that communicates to a GSCL using the dIa reference point. D’ does not implement ETSI M2M Service Capabilities
• Non-ETSI M2M compliant device (d): A device that connects to a SCL through the SCL’s Interworking Proxy capability.

X.1 ETSI M2M Area Networks

In the ETSI framework D’ and d Devices that connect to a SCL within a M2M Device or Gateway are said to be “attached devices” and are organized by M2M Area Networks within the SCL. The mechanism that a M2M Gateway uses to identify M2M Area Networks and their associated devices is implementation specific.

X.2 Device:2 Data Model and Functionality for ETSI M2M REM

Annex B of the ETSI M2M Functional Architecture [15] provides a cross reference between the xREM management functions and the object instances and RPCs required to implement the management functionality. The following is a summary of the objects, services, components, RPCs and optional TR-069 functionality required by the ETSI M2M xREM solution.

The ETSI M2M xREM solution in Annex E of the ETSI M2M Managed Objects [[16] defines a cross reference of the following ETSI resources to the existing Device:2 Data Model objects. These ETSI resources are:

• etsiDeviceInfo
• etsiDeviceCapability
• etsiMemory
• etsiTrapEvent
• etsiPerformanceLog
• etsiFirmware
• etsiSoftware
• etsiReboot

The implementation of these resources the use of the following objects from the data model:

• DeviceInfo.
• WiFi.
• SmartCardReaders.
• USB.
• HomePlug.
• MoCA.
• UPA.
• UPnP.
• Hosts.
• SoftwareModules.
• FaultMgmt. (Use for etsiTrapEvent)
• SelfTestDiagnostics.
• DeviceInfo.VendorLogFile. (Use for etsiPerformanceLog)
• ManagementServer.EmbeddedDevice.
• ManagementServer.VirtualDevice.

X.2.1 TR-069 Functionality for ETSI M2M REM

In addition to the mandatory RPCs defined in TR-069 [2], the ETSI M2M xREM solution requires that a M2M Device or Gateway implement the following optional RPCs according to Section 9.2.1.11 of [15]:

• Upload method
• ScheduleDownload method
• ScheduleInform method
• ChangeDUState method
• FactoryReset method

X.3 Device:2 Data Model and Functionality for ETSI M2M REM

In addition to reusing objects and parameters, the ETSI M2M xREM solution defines extensions to the resource model for the following ETSI resources by defining extensions to the data model for the following ETSI resources:

• etsiSclMo
• etsiAreaNwkInfo
• etsiAreaNwkDeviceInfo

These resources provide administration of the SCL in order for the SCL in the Device or Gateway to communicate with SCLs in the network. In addition, these resources provide administration of the SCL for M2M Devices within the local M2M area network attached to a Device or Gateway in order to communicate with associated network SCLs.

The ETSI M2M Services Device model defines the ETSIM2M service in support of the xREM functionality.

X.3.1 M2M Service SCL Execution Environment

CPEs that provide software execution capabilities have the option to implement the Gateway Service Capabilities Layer and Gateway Applications as software modules. When a SCL is implemented as a software module, each instance of the GSCL and GA would be represented as individual Deployment Units with the associated software and configuration files. For the GSCL the vendor configuration file could contain configuration elements (e.g., M2M Node Id, NSCL List) that would be returned from or necessary to perform the M2M Service Bootstrap and Service Connection Procedures.

X.3.2 ETSIM2M Object

The ETSIM2M objects provide administration of the SCL instantiated within a Device or Gateway.

The primary administration functions of the service are to:

• Maintain the set of Network SCLs (NSCL) that the M2M Device or Gateway SCL is registered.
• Maintain the set of NSCLs to which the M2M Device or Gateway will “announce” local resources.
• Maintain a list of Store and Forward (SAF) policies associated with the access network provider for message handling between M2M Devices in the area network and the NSCL.
• Maintain a list of Store and Forward (SAF) policies associated with the access network provider for message handling between the gateway and the NSCL.
• Maintain a list of Store and Forward (SAF) policies associated with the M2M service provider for message handling between M2M Devices in the area network and the NSCL.
• Maintain a list of Store and Forward (SAF) policies associated with the M2M service provider for message handling between the gateway and the NSCL.
• Discovery and Maintenance of M2M Area Networks.
• Discovery and Maintenance of M2M Devices.

X.3.2.1 M2M Service Bootstrap and Service Connection Procedures

In the ETSI M2M system, the M2M (Device or Gateway) Node must establish the capability to connect with a M2M Network Node before the SCLs are permitted to be registered using M2M Service Bootstrap and Service Connection procedures.

The M2M Service Bootstrap and Service Connection procedures are defined in section 8.2 of the ETSI M2M Functional Architecture [15] and describe how some of the credentials are shared and obtained in order to establish a connections (e.g, HTTP TLS-PSK) during the exchange of RESTFul information over the mId reference point.

X.3.2.2 Rules for Instantiating a SCL Instance

A M2M Node is not modeled as a device management entity but is considered a logical representation of the M2M components in the M2M Device, M2M Gateway or the M2M Core. Such components include:

• One instance of a SCL
• An optional M2M Service Bootstrap procedure
• A M2M Service Connection procedure

A M2M Node is identified by a globally unique identifier, the M2M-Node-ID.

In addition to the logical representation of a M2M Node, the following are constraints of a M2M Node that reflect on why a M2M Device or Gateway would instantiate multiple SCL instances:

• A M2M Node is owned by one M2M Service Provider.
• A M2M Node is instantiated upon M2M Bootstrap procedure or pre-provisioning the M2M Device or Gateway with a M2M Service Provider.
• Multiple M2M Nodes MAY be instantiated on the same M2M Device or Gateway by performing multiple M2M Bootstrap procedures either with the same M2M Service Provider or with different M2M Service Providers.

X.3.2.3 SCL Addressing

When a SCL is instantiated the SCL is provided a SCL-ID using the M2M Service Bootstrap procedure or through an out-of-band mechanism. Table 7.1 of the ETSI M2M Functional Architecture [15] describes the characteristics of the SCL-ID.

When a M2M Device or Gateway SCL registers with a NSCL, the NSCL maintains the following information in its resource tree for the SCL that allows the NSCL to identify and contact the M2M Device or Gateway SCL:

• SCL-ID that globally unique and MAY be the same as the M2M-Node-ID.
• M2MPoCs contactInfo of the M2M Device or Gateway SCL – This MAY be the FQDN, IP Address and port information or it MAY be other information that the M2M Service Provider can use to ask the network access provider for an IP Address.

X.3.2.4 SCL Registration

In order to communicate requests between the M2M Device or Gateway SCL and the NSCL, the M2M Device or Gateway SCL registers with the NSCL. Section 9.3.2.6.2 of the ETSI M2M Functional Architecture [15] describes the registration process including how attributes such as the SCLID, search strings and expiration times are provisioned. In order for a M2M Device or Gateway SCL to register with the NSCL, the M2M Device or Gateway SCL must be provisioned with a list of potential NSCLs that the M2M Device or Gateway SCL is registered. In addition to the list of NSCLs, the M2M Device or Gateway SCL also has parameters to manage when a M2M Device or Gateway SCL re-registers with the NSCL. The M2M Device or Gateway SCL also has the capability to be requested to re-register with the NSCL through its TR-069 interface.

X.3.2.5 Discovery of M2M Devices through the SCL

Using the control plane, the M2M Device or Gateway SCL provides the capability to return a list of resources that the M2M Device or Gateway has discovered. Filtering MUST be performed on a subset of the offered resources’ attributes using a query string. A match, that MAY include ranges, is performed on the query string, and a successful response is returned with a URI(s) list for resources that contains the matching attributes. Section 9.3.2.27 of the ETSI M2M Functional Architecture [15] describes this procedure. The M2M Device or Gateway MAY be provisioned through the TR-069 interface to either limit the number of URIs discovered by the device or define the maximum size allowed for a discovery result.

X.3.2.6 De/Announcing M2M Devices through the SCL

One capability of the M2M Device or Gateway SCL control plane is to announce or de-announce M2M resources (e.g., access rights, applications) to NSCL(s) to which the M2M Device or Gateway SCL has registered if the SCL is contained within the “AnnounceToSCLList”. Section 9.3.2.28 of the ETSI M2M Functional Architecture [15] describes this procedure. The “AnnouncedToSCLList” is maintained through the TR-069 interface.

X.3.2.7 SCL Store and Forward Policies

The M2M Device or Gateway SCL is responsible for handling requests from an attached M2M Device or itself and the NSCL. The handling of the requests is based on criteria within the request (e.g., Request category [RCAT], Tolerable Request Processing Delay [TRPDT]) as well as conditions within the M2M Device or Gateway SCL (e.g., pending requests, access network availability).

There are two types of SCL store and forward (SAF) policies:

• Access Network Provider SAF Policies
• Service Provider SAF Policies

The SAF policies are organized into instances of Policy sets. The selection of which Policy sets are used by the M2M Device or Gateway SCL is determined by the PolicyScope attribute of the Policy set.

Section 9.3.1.5 of the ETSI M2M Functional Architecture [15] describes this procedure. These policies are maintained through the TR-069 interface.

X.3.2.7.1 Access Network Provider SAF Policies

Access Network Provider SAF policies are used by M2M Device or Gateway SCLs to determine if an Access Network is to be used when forwarding requests from the M2M Device or Gateway SCL to the NSCL. The determination of which Access network to use is based on:

• Schedule of RCAT values versus time: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the access network provider regarding when it is appropriate to forward requests of a given RCAT value.
• Blocking of access attempts after failure to establish connectivity: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the access network provider regarding the period of time over which attempts to establish connectivity over its access network are not appropriate after the previous attempt to establish connectivity over the corresponding access network has failed. The period of time to block attempts to establish connectivity can be a function of the number of consecutive previous attempts to establish connectivity over this access network.

X.3.2.7.2 M2M Service Provider SAF Policies

M2M Service Provider Store and Forward (SAF) policies are used by M2M Device or Gateway SCLs to determine to forward a request to NSCL. The determination if the request is forwarded is based on the:

• Wait time as function of number of pending requests: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the service provider regarding how many pending requests of a given range of RCAT values are sufficient to forward the aggregated request to the NSCL. The ranges of RCAT values for different policies cannot overlap.
• Wait time as function of amount of pending request data: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the service provider regarding a threshold of consumed storage (memory) in the M2M Device or Gateway SCL that is needed to buffer data for pending requests of a given range of RCAT values. The ranges of RCAT values for different policies cannot overlap.
• Selection among appropriate access networks: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the service provider regarding how to select an access network for making an attempt to establish connectivity from an ordered list of possible access networks for a given range of RCAT values. The ranges of RCAT values for different policies cannot overlap.
• Default values for TRPDT and RCAT: The M2M Device or Gateway SCL is provisioned with information from the NSCL for the service provider regarding the TRPDT and RCAT values to use if they are not provided by the request issuer.

X.3.2.8 Area Network Discovery and Maintenance

The M2M Device or Gateway SCL discovers properties of instances of M2M Area Networks as well as the Devices (D’, d) associated with a M2M Area Network. A M2M Area Network is a logical entity in that an instance of an Area Network can span one or more physical interfaces of the M2M Device or Gateway. In addition, a M2M Gateway can provide connectivity to more than one instance of the same type of M2M Area Network. Examples of M2M Area Networks include: Personal Area Network technologies such as IEEE 802.15.x, Zigbee, Bluetooth, IETF ROLL, ISA100.11a or local networks such as PLC, M-BUS, Wireless M-BUS and KNX.

A M2M Area Network is maintained as instances of an AreaNwkInstance. Each AreaNwkInstance maintains opaque properties of the Area Network using Property instances of name/value pairs. In addition, the AreaNwkInstance also maintains a list of references to instances of AreaNwkDeviceInfoInstance table that are associated with the Area Network.

X.3.2.9 M2M Device Discovery and Maintenance

The M2M Device or Gateway maintains a list of discovered M2M Devices (D’, d) that are attached to the SCL. A discovered M2M Device that is associated with more than one AreaNwkInstance is represented as multiple instances of AreaNwkDeviceInfoInstance objects.

In Figure 56, an M2M Gateway has two (2) SCL instances that manage three (3) M2M Devices. Each M2M Device is represented in the Root Data Model’s Hosts.Host table. The M2M Devices are represented by the AreaNwkDeviceInfoInstance object that was discovered within a context of an AreaNwkInstance of a SCL. As a M2M Device is capable of being discovered through multiple M2M Area Networks, different instances of the AreaNwkDeviceInfoInstance could reference the same or different Host table entry.

Each AreaNwkDeviceInfoInstance maintains a reference to an AreaNwkInstance object as well as properties specific to the device and area network association (e.g., SleepInterval). In addition, each AreaNwkDeviceInfoInstance maintains opaque properties of the device using Property instances of name/value pairs.

X.3.2.9.1 M2M Device Discovery and Maintenance

M2M Devices are able to be managed through the TR-069 Embedded Object and Virtual Device Proxy management capabilities. In these scenarios the AreaNwkDeviceInfoInstances are known as Discovered Devices.

In the scenario where a M2M Device (D’, d) is discovered as part of an Embedded or Virtual Device, the AreaNwkDeviceInfoInstance is maintained as an item in the DiscoveryProtocolReference parameter of the Embedded or Virtual Device using one or more of the protocols listed in the DiscoveryProtocol parameter. Figure 57 describes the scenario where the M2M Devices are discovered using the ETSI-M2M protocols.

X.3.2.10 SCL Configuration

The ETSI M2M Data Model includes the capability to provision the SCL with objects and parameters necessary for the SCL to host resources and transfer messages between M2M Devices and Gateway Applications and the NSCL. This section describes the minimal configuration necessary for an SCL to:

• Host resources
• Transfer messages

Figure 58 depicts the objects within an ETSI SCL instance.

For deployments where the SCL will only host resources, the following resources must be provisioned:

SCL.{1}.
    Enable = true

However for deployments where the SCL will transfer messages between M2M Applications and the NSCL, each SCL must have:

• An enabled SCL
• An enabled default SAFPolicySet
• At least 1 enabled ANPPolicy with an enabled Schedule for each of the enabled RequestCategory. There is one enabled RequestCategory instance for each possible RCAT value (e.g., 8 possible values in ETSI release 1.0)
• Within the M2MSPPolicy, there is one enabled RequestCategory instance for each possible RCAT value (e.g., 8 possible values in ETSI release 1.0)

As such the following resources must be provisioned:

SCL.{1}.
    Enable = true
SCL.{1}.SAFPolicySet.{1}.
    Enable = true
    PolicyScope= default
SCL.{1}.SAFPolicySet.{1}.ANPPolicy.{1}.
    Enable = true
    ANName = *AccessNetworkProviderName*
SCL.{1}.SAFPolicySet.{1}.ANPPolicy.{1}.RequestCategory.{1}.
    Enable = true
    RCAT = *RCAT1*
SCL.{1}.SAFPolicySet.{1}.ANPPolicy.{1}.RequestCategory.{1}.Schedule.{1}.
    Enable = true
    Schedules = * * * * *
.
.
SCL.{1}.SAFPolicySet.{1}.ANPPolicy.{1}.RequestCategory.{7}.
    Enable = true
    RCAT = *RCAT7*
SCL.{1}.SAFPolicySet.{1}.ANPPolicy.{1}.RequestCategory.{7}.Schedule.{1}.
    Enable = true
    Schedules = * * * * *
SCL.{1}.SAFPolicySet.{1}.M2MSPPolicy.RequestCategory.{1}.
    Enable = true
    RCAT = *RCAT7*
*    *RankedANList = *AccessNetworkProviderName*
.
.
SCL.{1}.SAFPolicySet.{1}.M2MSPPolicy.RequestCategory.{7}.
    Enable = true
    RCAT = *RCAT7*
    RankedANList = *AccessNetworkProviderName*

Appendix XI: Provider Bridge Theory of Operation

A Provider Bridge is defined in 802.1Q-2011 [21] as either a Provider Edge Bridge (PEP) or an S-VLAN Bridge. A PEP provides the capability to stack VLAN tags with the inner tag being the C-TAG and the outer tag being the S-TAG. An S-VLAN Bridge provides a mechanism to process a S-TAG but does not utilize the mechanism to stack C-VLAN tags. The Provider Bridge model supports both of these types of Provider Bridges through the use of the ProviderBridge and VLANTermination objects.

Regarding different traffic bridging rules for Provider Bridges, the possible cases are characterized as follows:

• Provider Edge Bridge as a pure VLAN Bridge
• Stacked VLAN termination in a routed environment
• Internally generated to tagged WAN traffic as a S-VLAN Termination

These scenarios are portrayed in Figure 59, where:

• Residential Domain traffic is treated as a Stacked VLAN termination in a routed environment
• Public Domain and Roaming Domain traffic is treated as a Provider Edge Bridge in a pure VLAN Bridge environment
• Internally generated Device traffic is treated as a S-VLAN termination in a routed environment

In order to model the traffic scenarios in Figure 59, the use of the VLANTermination and Bridging Objects are used.

XI.1 Residential Domain Scenario

In the Residential Domain scenario untagged traffic is routed from the Ethernet and SSIDa interfaces and tagged with a customer VLAN tag (C-TAG) of VLANa and then double tagged with a Service Provider VLAN tag (S-TAG) of VLANx. This requires the use of:

• 802.1d Bridge instance: This object bridges the residential domain traffic to the Router.
• Layer3 Forwarding Rule: This object ensures that traffic between the Bridge and VLANTermination objects is forwarded to the correct interface. The Rule utilizes the IP Interfaces of the Bridge (IP Intf: Bridge_a) and Residential Domain (IP Intf: Residential)
• VLANTermination object (C-TAG): The C-TAG is applied and removed for traffic egress and ingress to the IP Intf: Residential interface.
• VLANTermination object (S-TAG): The S-TAG is applied and removed for traffic from and to the C-VLAN termination object.

XI.2 Device Traffic Scenario

In the Device Traffic scenario untagged traffic is routed from the Device and tagged with a Service Provider VLAN tag (S-TAG) of VLANu. This requires the use of:

• VLANTermination object (S-TAG): The S-TAG is applied and removed for traffic egress and ingress to the IP Intf: Device interface.

XI.3 Public and Roaming Domain Scenarios

In the Public and Roaming Domain scenarios untagged traffic is bridged from the SSIDb and SSIDc interfaces and tagged with a customer VLAN tag (C-TAG) of VLANa and then double tagged with a Service Provider VLAN tag (S-TAG) of VLANy and VLANz respectively. This requires the use of:

• ProviderBridge instance: This object contains and references the customer and service provider bridge components.
• Bridge instance (Customer Public): This object bridges and tags (C-TAG) traffic in the Public Domain to the service provider bridge component.
• Bridge instance (Customer Roaming): This object bridges and tags (C-TAG) traffic in the Roaming Domain to the service provider bridge component.
• Bridge instance (Service Provider): This object add and removes a service provider tag (S-TAG) for customer tagged traffic (C-VLAN) from the Pubic and Roaming Domains.

XI.4 Provisioning Provider Bridges

A Provider Bridge provides support for Provider Bridges and Provider Edge Bridges as defined in 802.1Q-2011. The difference between a Provider Bridge and a Provider Edge Bridge is that a Provider Edge Bridge incorporates a C-TAG and S-TAG while a Provider Bridge has a S-TAG. The data model differentiates which type of provider using the Type parameter of the ProviderBridge.{i} object.

When configuring the components of a Provider Bridge, the Bridge instance associated with the SVLAN component will have its Device.Bridging.Bridge.{i}.Port.{i}. objects provisioned as either ProviderNetworkPort or a CustomerNetworkPort. Likewise, the CVLAN component(s) will have its Device.Bridging.Bridge.{i}.Port.{i}. objects provisioned as CustomerEdgePorts.

XI.4.1 Associating Customer Edge Ports with Customer Network Ports

Ports of type CustomerEdgePort are associated with ports of type CustomerNetworkPort by assigning the ports of type CustomerNetworkPort and ports of type CustomerEdgePort to the port membership (Bridging.Bridge.{i}.VLANPort.{i}.) of the S-VLAN for the Bridge instance of the S-VLAN component.

Appendix XII: ZigBee Theory of Operation

This section explains how the ZigBee Device:2 data model can be used for the management of ZigBee devices.

XII.1 CWMP management using the ZigBee data model

Figure 61 and Figure 62 present the principle and an example basic sequence for the management of ZigBee devices using the Device:2 ZigBee data model. The ZigBee protocol is specified in [71].

The ZigBee devices reside behind a device proxy and communicate with the ACS via this device proxy. The device proxy normally resides in a device such as a broadband router, i.e., a home gateway or an enterprise gateway, and it has a proxy function to translate CWMP messages to ZDO (ZigBee Device Object) function invocations based on the ZigBee data model. The proxy function translates the messages by using a mapping of ZigBee data model objects and CWMP methods to ZDO functions and their parameters. A ZigBee device management example using CWMP is shown in Figure 61.

This example shows how the ACS gets the network address of a ZigBee device by using TR-069 communication based on the ZigBee data model. The ACS performs a “GetParameterValues” CWMP method call containing the parameter “Device.ZigBee.ZDO.{i}.NetworkAddress” of the ZigBee data model, which refers to the ZigBee network address. The proxy function in the device proxy changes the received message to a ZDO message that calls some ZDO function on the ZigBee Coordinator. The ZigBee Coordinator manages the ZigBee devices according to the called ZDO function and sends the result (the searched network address, in this case) to the proxy. The proxy function changes the ZDO management result to a CWMP message which is denoted in Figure 62 as “GetParameterValuesResponse”. The parameter name inside the parameter list is “Device.ZigBee.ZDO.{i}.NetworkAddress” and the corresponding value is “0x0fE3” (network address instance).

XII.2 CWMP proxying mechanisms and the ZigBee data model

The following two issues related to the proxying of ZigBee devices with the standard TR-069 proxying mechanisms are out of scope of this document:

• Mapping of TR-069 methods plus data model objects/parameters to ZDO functions.
• Description of the exact approaches (and their differences) for proxying a ZigBee device (i) as a Virtual Device or (ii) as an Embedded Device.

However, the following example explains how the main needs of the proxying mechanisms have been taken into account and are covered by the designed data model.

Imagine, for example, a ZigBee coordinator that controls a network which contains, among others, a ZigBee device that is used in a home automation system, i.e., implements the Home Automation Application Profile (0104). Then, the instantiation of the data model for the device contains, among others, the following two parameter values (note that “ZC” stands for ZigBee coordinator):

Device.ZigBee.ZDO.1.NodeDescriptor.LogicalType = "ZC"
Device.ZigBee.ZDO.2.ApplicationEndpoint.1.ApplicationProfileId = "0104"

In order to reference and manage these devices with the EmbeddedDevice mechanism, the device instance would simply also include, among others, the following entries:

Device.ManagementServer.EmbeddedDevice.1.Reference

• (pointing to) Device.DeviceInfo.TemperatureStatus.TemperatureSensor.2

Device.ManagementServer.EmbeddedDevice.1.ProtocolReference

• (pointing to) Device.ZigBee.ZDO.2.ApplicationEndpoint.1

Device.ManagementServer.EmbeddedDevice.2.DiscoveryReference

• (pointing to) Device.ZigBee.ZDO.1

For setting the temperature for TemperatureSensor.2, for example, the TR-069 proxy would send a request through the ZigBee coordinator to the Application endpoint referenced by the ProxyReference parameter on the EmbeddedDevice instance. As indicated by the value of Device.ManagementServer.EmbeddedDevice.1.Reference in the above example, multiple sensors integrated in the same ZigBee device (i.e., same ZDO instance) can be modeled as different Embedded or Virtual devices while referring to the same ZDO object.

According to the ZigBee protocol, the discovery of ZigBee devices is the responsibility of the ZigBee coordinator. Thus, a ZDO instance that has a LogicalType=“ZC” can be made a DiscoveryReference of the various EmbeddedDevice and VirtualDevice instances.

Appendix XIII: Port Control Protocol Theory of Operation

The Port Control Protocol (PCP) allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall (generically referred to as the “PCP-controlled device”), and also allows a host to optimize its outgoing NAT keepalive messages.

When a PCP client is embedded in a device, the PCP client can be invoked by:

• Applications running on the device itself (remote access, VoIP…),
• The device GUI,
• The Controller,
• Interworking functions [57] and the PCP proxy that allow applications running on other end-devices connected to the device to manage the PCP-controlled device.

Defining a PCP data model allows the Controller to remotely manage the PCP client including:

• Configuration and monitoring of the PCP client itself,
• Configuration and monitoring of the PCP servers interacting with the client,
• Monitoring PCP Interworking Functions,
• Monitoring and setting rules in the PCP-controlled device from the PCP client.

Whereas the description of objects themselves is enough to understand how to proceed, some operations need further explanation about the way to manage the objects.

This theory of operation relies on IETF RFCs and drafts:

• RFC 6887 Port Control Protocol (PCP) [56],
• RFC 6970 UPnP IGD-PCP Interworking Function [57],
• DHCP Options for the Port Control Protocol (PCP) [58],
• Port Control Protocol (PCP) Proxy Function [64],
• PCP Server Selection [59],
• PCP Flow Examples [22].

The data model allows for more than one PCP client, but those clients operate independently. Therefore, the text below considers only one PCP client.

XIII.1 Configuration and monitoring of the PCP Server

Prior to sending its first PCP message, the PCP client determines which server to use as described in [59]. To do so the PCP client of the device can be configured statically (GUI or CWMP) or via DHCP (v4 or v6).

• When configured via DHCP, the device receives a list (at least one) of PCP server addresses in one or more OPTION_V4_PCP_SERVER or OPTION_V6_PCP_SERVER DHCP options. Based on the content of these DHCP options, the device creates one or more instances of PCP.Client.{i}.Server (see [58]). The list of addresses provided for each PCP server is stored in the ServerNameOrAddress and AdditionalServerAddresses parameters and the Origin parameter is set to either “DHCPv4” or “DHCPv6”.

• When statically configured, one instance of PCP.Client.{i}.Server is created per server, with the Origin parameter set to “Static”. The server is defined by either an FQDN or an IP address in ServerNameOrAddress.

Based on these server definitions, the PCP client follows the procedures specified in [59] to determine the IP Address to be used for each configured PCP server.

• While the PCP client is trying to connect to a PCP server on a given IP address, the PCP.Client.{i}.Server object’s ServerAddressInUse holds that IP address and its Status is “Connecting”.

• When the PCP client has successfully received a response from a server, Status becomes “Enabled” and server-discovered properties (CurrentVersion, Capabilities…) are stored in the corresponding parameters.

• If the PCP client fails to connect to a given PCP server, ServerAddressInUse remains the last IP address tried and Status reflects the appropriate error condition.

No conflict or doubt can arise between DHCP and static configurations, because they are represented in separate PCP.Client.{i}.Server instances, with Origin to record the origin of the configuration. ServerNameOrAddress is writable by the Controller only if Origin is “Static”.

XIII.2 Monitoring and setting rules set by the PCP client

Once a PCP server has been successfully contacted, the PCP client is ready to set rules in the corresponding PCP-controlled device. Depending on the use case, the PCP client selects the appropriate PCP server based on its Capabilities, as described in Section 10 of [56]. It is possible to define the following mappings:

Inbound Mapping without filters
An inbound mapping is defined by an instance of the PCP.Client.{i}.Server.{i}.InboundMapping table. It is created by a PCP request with the MAP OpCode, as described in Section 11 of [56]. This is allowed only if PCP.Client.{i}.MAPEnable is “true”.

Inbound Mapping with filters
As above, but additional filters are defined by instances of the PCP.Client.{i}.Server.{i}.InboundMapping.{i}.Filter table. Filters are specified in the PCP request using the FILTER option, as described in Section 13.3 of [56]. This is allowed only if PCP.Client.{i}.FILTEREnable is “true”.

Outbound Mapping
An outbound mapping is defined by an instance of the PCP.Client.{i}.Server.{i}.OutboundMapping table. It is created by a PCP request with the PEER OpCode, as described in Section 12 of [56]. This is allowed only if PCP.Client.{i}.PEEREnable is “true”.

It is possible to define a mapping on behalf of another device. The PCP request uses the THIRD_PARTY option to create the mapping, as described in Section 13.1 of [56]. This is allowed only if PCP.Client.{i}.THIRDPARTYStatus is “Enabled”.

These operations can be requested by the device itself (embedded applications, GUI, CWMP…) or by another device through the UPnP IGD interworking function [57] (if PCP.Client.{i}.UPnPIWF.Status is “Enabled”) or the PCP Proxy [64] (if PCP.Client.{i}.PCPProxy.Status is “Enabled”).

[22] provides a set of examples to illustrate PCP operations. These operations can be monitored by getting PCP.Client.{i}.Server.{i}.InboundMapping and PCP.Client.{i}.Server.{i}.OutboundMapping objects. The parameters sent by the PCP client in MAP or PEER requests are represented in corresponding parameters (Lifetime, SuggestedExternalIPAddress, SuggestedExternalPort, SuggestedExternalPortEndRange, ProtocolNumber, InternalPort…) of PCP.Client.Server.{i}.InboundMapping and PCP.Client.Server.{i}.OutboundMapping. The Origin parameter denotes which mechanism triggered the request:

• “Internal” for an embedded application,
• “Static” for a request issued from the GUI or set using CWMP (see next paragraph),
• “UPnP_IWF” for a UPnP IGD device,
• “PCP_Proxy” for a PCP device.

The parameters received when the PCP-controlled device has processed the request are represented in corresponding parameters (Lifetime, AssignedExternalIPAddress, AssignedExternalPort, AssignedExternalPortEndRange…) of PCP.Client.{i}.Server.{i}.InboundMapping and PCP.Client.{i}.Server.{i}.OutboundMapping.

To remotely create rules using CWMP or USP, the Controller configures the request to be sent by the PCP Client. To do so the Controller creates the necessary objects and sets, depending on the operation, the Lifetime, SuggestedExternalIPAddress, SuggestedExternalPort, SuggestedExternalPortEndRange, ProtocolNumber, InternalPort parameters of PCP.Client.{i}.Server.{i}.InboundMapping or of PCP.Client.{i}.Server.{i}.OutboundMapping. To monitor the result, the Controller will get PCP.Client.{i}.Server.{i}.InboundMapping and PCP.Client.{i}.Server.{i}.OutboundMapping objects to retrieve the parameters received from the PCP-controlled device.

XIII.3 Rapid recovery

A recovery mechanism for situations where the PCP server loses its state is described in Section 14 of [56]. This is usable only if PCP.Client.{i}.ANNOUNCEEnable is “true”.

Appendix XIV: GRE Tunnel Theory of Operation

See Tunneling for general information on how tunneling is modeled.

RFC 2784 [28] defines a generic mechanism to encapsulate a packet of protocol A (known as the payload protocol) in a GRE packet. The resulting GRE packet is then encapsulated into a protocol B (known as the delivery protocol). The result of this operation is a payload packet that is encapsulated in a GRE tunnel delivered via protocol B. RFC 2890 [30] extends the GRE header with two optional fields. The Key field provides an identifier to identify flows within the GRE tunnel. The Sequence Number field is used to maintain the sequence of packets within the GRE tunnel.

Device:2 models a GRE tunnel using the GRE.Tunnel object. Multiple GRE flows to the same remote endpoint are possible by defining multiple GRE.Tunnel.{i}.Interface instances within the same GRE.Tunnel instance.

This Appendix describes the usage of GRE for two scenarios: L2 payload over GRE and L3 payload over GRE.

XIV.1 L2 Payload over GRE

For this example consider a Provider Edge Bridge that discriminates 2 separate VLANs as shown in Figure 65. In this case the service provider does not support a VLAN infrastructure at the access node, but does at the core network.

A GRE tunnel is used to preserve the VLAN tagging at the edge to further interconnect the other VLAN segments. In this scenario, as the remote endpoint is the same in both cases, the VLANs are modeled as two flows within a single instance of the GRE.Tunnel.{i} object.

In addition, the DSCPMarkPolicy parameter can be used to assign DSCP values to each GRE.Tunnel.{i}.Interface instance for QoS treatment in the access network and towards the GRE concentrator.

The GRE Tunnel interface layout is shown in Figure 66.

The configuration for this scenario assumes that the WAN Ethernet interface, Ethernet Link and IP interface objects have been previously configured; likewise the LAN Ethernet and Bridging objects have been previously configured. This section focuses on the association and configuration of the GRE tunnel with the WAN IP interface and the Bridge Ports.

The example configuration uses the RFC 2890 [30] Key field to determine the GRE tunnel interface to which the GRE tunnel will forward packets.

XIV.2 L3 Payload over GRE

This example describes an IP in IP encapsulation where a GRE tunnel takes IPv4 payload and encapsulates over IPv6.

Figure 67 shows the scenario where an IPv4 LAN network is tunneled in an IPv6 GRE tunnel that uses IPv6 global addresses.

The GRE tunnels use the default IPv6 WAN interface of the device.

Figure 68 shows the configuration of a GRE tunnel for an IPv4 Private network attached to a LAN interface that is encapsulated in the IPv6 packet.

The configuration for this scenario assumes that the WAN and LAN Ethernet interface, Ethernet Link and IP interface objects have been previously configured. This section focuses on the association and configuration of the GRE tunnel with the WAN and Tunnel IP interfaces.

Appendix XV: MAP Theory of Operation

See Tunneling for general information on how tunneling is modeled.

MAP (Mapping of Address and Port) is a mechanism for transporting IPv4 packets across an IPv6 network, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and ports. There are two mutually exclusive MAP transport modes, both of which use NAPT44 (modified to use a restricted port range):

• MAP-E (Encapsulation) [61] uses an IPv4-in-IPv6 tunnel.
• MAP-T (Translation) [63] uses stateless NAT64.

Many aspects of the MAP configuration are the same for both MAP-E and MAP-T. [62] defines DHCPv6 options for configuring MAP parameters, and the Device:2 data model parameters correspond closely to these parameters.

XV.1 MAP Configuration Parameters

The MAP-T architecture is illustrated in Figure 69. The MAP-E architecture diagram looks very similar, but differs as follows:

• The device’s MAP function involves 6-4 encapsulation rather than 6-4 translation.
• The device uses a Border Router (BR) IPv6 address rather than a prefix.
• Non MAP-aware servers (i.e., native IPv6 servers) can’t be reached by IPv4 devices behind the device (i.e., can’t be part of the MAP domain).

The Device:2 data model models each MAP domain as an instance of the corresponding MAP.Domain table. The most important domain parameters are:

• TransportMode: “Encapsulation” (MAP-E) or “Translation” (MAP-T).
• WANInterface: the WAN IP interface through which all MAP traffic will flow.
• IPv6Prefix: end-user IPv6 prefix; one of this interface’s prefixes, typically assigned via DHCPv6 Prefix Delegation.
• BRIPv6Prefix: the Border Router IPv6 prefix (MAP-T mode) or IPv6 address (MAP-E mode).
• DSCPMarkPolicy: governs DSCP selection when encapsulating / translating.
• PSIDOffset etc: parameters defining Port-sets ([61] Section 5.1).

Each domain has a set of mapping rules ([61] Section 5) with each rule having the following parameters:

• IPv6Prefix: the IPv6 prefix for this rule.
• IPv4Prefix: the IPv4 prefix for this rule.
• EABitsLength: the length of the EA (Embedded Address) bits for this rule.
• IsFMR: whether this rule is an FMR (Forwarding Mapping Rule).

The mapping rule with the longest match between its IPv6Prefix and the end-user IPv6 prefix is the BMR (Basic Mapping Rule). This is used to determine the MAP IPv6 address, which is one of Interface’s addresses and is used for all MAP traffic.

XV.2 Internal Treatment of IPv4 Packets

Since a device can have multiple upstream and multiple downstream interfaces, the model supports a logical representation of the internal virtual MAP IPv4 interface according to the general pattern described in Tunneling. The IPv4Forwarding entries will route traffic between the LAN IPv4 interface and the MAP IPv4 interface.

Figure 70 shows the flow of MAP traffic through the various interfaces. Noted in the figure are sample values for the various IP.Interface entries that would be needed.

Figure 71 shows the corresponding MAP interface stack.

Appendix XVI: G.fast Theory of Operation

G.fast (hereafter referred to as FAST) is a DSL communications technology defined by ITU-T G.9700, G.9701, and G.997.2.

Devices that support both DSL and FAST (both interfaces’ objects are administratively Enabled) have the capability to switch from one mode to another. If the device is connected in xDSL mode (DSL.Line.{i}.status is “Up”), FAST interface is down (FAST.Line.{i}.status is “Not Present” or “Down”). The InterfaceStack Table needs to reflect the relationship between the PTM interface and DSL interface as seen in Figure 72. The PTM’s LowerLayers points to DSL.Channel instance whose status is “Up”.

In the case when the device is connected in FAST mode, the DSL line is down. The InterfaceStack Table needs to show that the PTM’s LowerLayers points to the FAST.Line interface as below:

The same fall back mechanism applies to the bonding of FAST and DSL interfaces. PTM’s interface is to be stacked on two bonding groups as they are both administrative “Enable”. However, in the InterfaceStack Table, the PTM interface’s LowerLayers points to the bonding group that has Operational Status “Up”. In the diagram below, PTM’s LowerLayers points to the bonding group of FAST.Line, which is currently “Up”. The DSL bonding group instance corresponding to DSL channels is “Down”.

In the case where DSL Bonding group is “Up” for non-FAST mode lines, the diagram below shows PTM’s LowerLayers pointing to the bonding group of DSL.Channel, which is currently “Up”. The DSL bonding group instance corresponding to FAST Lines is “Down” here.

Appendix XVII: USB Host Theory of Operation

XVII.1 Overview

An increasing number of devices are equipped with a USB Host controller and USB host interface(s) / connector(s).

There are a number of use cases for adding a USB Host and connected devices to a CWMP data model. One example is retrieving the exact product identity of the connected device in the event of service issues such as printer or file sharing problems. Another example is notifying the user that a newly-connected device is not supported, e.g., due to a missing driver. Or the detection of the connection of a particular USB device could mean additional services for this device could be offered to the subscriber.

The data model contains the number of devices connected to each host controller. For each device, the main properties of the USB device descriptors as well as interface descriptors are represented. The latter is to support devices that only indicate class/subclass (and therefore device type) at the interface level.

Example USB topology of connected devices:

All USB devices attach to a USB Host through a port on a USB entity known as a hub. Hubs have status bits that are used to report the attachment or removal of a USB device on one of its ports. The USB Host queries the hub to retrieve these status bits. In the case of an attachment, the USB Host enables the port and addresses the USB device through the device’s control pipe at the default address. Figure 76 depicts both a Root Hub and an External Hub that provide this service.

The USB Host assigns a unique USB address to the device and then determines if the newly attached USB device is a hub or function. The USB Host establishes its end of the control pipe for the USB using the assigned USB address and endpoint number zero. This is reflected in the data model by adding a new USBHosts.Host.{i}.Device.{i}. instance.

If the attached USB device is a hub and USB devices are attached to its ports, then the above procedure is followed for each of the attached USB devices.

If the attached USB device is a function, then attachment notifications will be handled by the USB Host software that is appropriate for the function.

Appendix XVIII: Location Management

This section discusses the Theory of Operation for Location Management using CWMP [2] or USP [11] and the Location object defined in the <rootobject>.DeviceInfo data model.

XVIII.1 Overview

The Location object defined in this document is a multi-instance object that can be used by any device that needs to be able to acquire and/or express its “location.”

This Location object is a multi instance object to account for the fact that a Device can acquire location information in more than one way. Location info can be acquired by:

• GPS/A-GPS, i.e., provided by specific on-board circuitry such as GPS or A-GPS;
• Manual, i.e., manually configured via the Device local GUI
• External, i.e., remotely configured via a number of protocols, including e.g., TR-069

Location objects can be created autonomously by the device, based on the location information it receives by CWMP or USP. When the Location object is created autonomously by the device, the device itself will fill the DataObject parameter with location data coming from GPS/AGPS, local GUI or an external protocol (not CWMP). When created by CWMP or USP, it is up to the CWMP or USP protocol to configure the DataObject parameter. Regardless of how a Location object is created, the device is responsible for populating the values of all of the location metadata (i.e., all parameters except the DataObject that contains the location information and the AcquiredTime) not writable by any external mechanism.

When a Location object is updated, the object can only be updated through the same mechanism that created it. The device will update the AcquiredTime as necessary and place the updated location data in the DataObject.

When a Location object is deleted, the object can only be deleted through the same mechanism that created it.

XVIII.2 Multiple Instances of Location Data

Devices that need to make use of location data will need to have rules around how to deal with multiple instances of location data. These rules are out of scope for CWMP or USP and the Device:2 data model. These rules may need to be specific to a particular application. For example, if a VoIP device chooses to send location data in a SIP message, the device can include all of the instances of DataObject in that message, order the Locations Objects according to the acquisition date and time (parameter AcquiredDateTime, most recent is first) or order the Location objects according to some sort of protocol preference, such as GPS, A-GPS, DHCP, HELD, CWMP, USP, and then all others according to acquisition date and time.

A Femtocell Access Point (FAP) with multiple sources of location can also need rules for use of the Location object. If it must make decisions locally based on location, the FAP will need rules to determine the preferred location. If the FAP must send its location elsewhere, the FAP will need rules to determine whether the FAP sends all of its location data, or selects certain locations based on specific criteria.

XVIII.3 CWMP, USP, Manual, GPS, and AGPS Configured Location

As noted in the description of the Device:2 data model parameter <rootObject>.Location.{i}.DataObject., Manual, GPS, and AGPS mechanisms are formatted by the device according to the following formats specified by the IETF. A Controller that is creating an External:CWMP or an External:USP location will use one of these formats:

1. Geographical coordinates formatted according to the XML syntax specified in IETF RFC 5491 [50] (update of RFC 4119 [37])

2. Civic addresses according to the XML syntax specified in IETF RFC 5139 [49] (update of RFC 4119 [37])

Location information in these IETF RFCs is specified within the IETF framework of presence information. While these IETF RFCs specify presence information different from the Location component model assumed in the TR-069 framework, the IETF data format is adopted by BBF independent of these higher level differences.

IETF defines its XML syntax for geographical information as a subset of presence information (<presence> object in the XML example below), generally related to a device (<device> object) or a user (<user> object). IETF location information is represented using a Presence Information Data Format Location Object (PIDF-LO). This is represented as the <geopriv> object in the XML example below.

XVIII.3.1 Example: Manual, GPS, AGPS, and External:CWMP <rootObject>.Location.{i}.DataObject. Format

This example, modified from an example in RFC5491, explains how to format location information in a <rootObject>.Location.{i}.DataObject. parameter with both geographical coordinates and civic location information according to the above-referenced IETF RFCs. The schema associated with the civic location namespace “urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr” is specified in RFC 5139 [49].

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          entity=" ">
    <dm:device id=" FFFFFF-FAP-123456789 ">
        <gp:geopriv>
            <gp:location-info>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                    <gml:pos>-43.5723 153.21760</gml:pos>
                </gml:Point>
                <cl:civicAddress>
                    <cl:FLR>2</cl:FLR>
                </cl:civicAddress>
            </gp:location-info>
            <gp:usage-rules/>
            <gp:method>Wiremap</gp:method>
        </gp:geopriv>
        <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
        <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
    </dm:device>
</presence>

XVIII.3.2 RFC 5491 and RFC 5139 Location Element Definitions

The XML elements are defined as follows by the IETF in RFC 5491 [50] and related documents:

1. <presence> (RFC 5491 [50])

   The <presence> element MUST have an ‘entity’ attribute. The value of the ‘entity’ attribute is the ‘pres’ URL of the presentity publishing this presence document.

   The <presence> element MUST contain a namespace declaration (‘xmlns’) to indicate the namespace on which the presence document is based. The presence document compliant to this specification MUST have the namespace ‘urn:ietf:params:xml:ns:pidf:’. It MAY contain other namespace declarations for the extensions used in the presence XML document.

2. <device> (RFC 5491 [50])

   The <device> element […] can appear as a child to <presence>. There can be zero or more occurrences of this element per document. Each <device> element has a mandatory “id” attribute, which contains the occurrence identifier for the device. In the TR-069 framework the id attribute will contain the CWMP Identifier of the device, in the form OUI-ProductClass-SerialNumber.

3. <geopriv> (RFC 5491 [50], RFC 5139 [49])

   Location information in a PIDF-LO can be described in a geospatial manner based on a subset of Geography Markup Language (GML) 3.1.1 or as civic location information specified in RFC 5139 [49]. The PIDF-LO Geodetic Shapes specification provides a specific GML profile for expressing commonly used shapes using simple GML representations. This profile defines eight shape types, the simplest ones being a 2-D and a 3-D Point. The PIDF-LO Geodetic Shapes specification also mandates the use of the World Geodetic System 1984 (WGS84) coordinate reference system and the usage of European Petroleum Survey Group (EPSG) code 4326 (as identified by the URN urn:ogc:def:crs:EPSG::4326) for two-dimensional (2d) shape representations and EPSG 4979 (as identified by the URN urn:ogc:def:crs:EPSG::4979) for three-dimensional (3d) volume representations.

   Each <geopriv> element must contain at least the following two child elements: <location-info> element and <usage-rules> element. One or more elements containing location information are contained inside a <location-info> element.

   1. <location-info> element can contain one or more elements bearing location information.
      1. <Point> element contains geographical data in the coordinate system specified by its srsName attribute. In the example above (WGS84/EPSG 4326), the syntax is latitude, longitude expressed in degrees
      2. Civic information elements are specified by IETF and can be added to the geographical data, though mixing information is not recommended.
      3. <relative-location> element is being proposed by IETF
   2. <usage-rules> can contain the following optional elements:
      1. <retransmission-allowed>: When the value of this element is ‘no’, the recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. RFC 4119 [37] specifies that “by default, the value MUST be assumed to be ‘no’”.
      2. <retention expires>: This field specifies an absolute date at which time the Recipient is no longer permitted to possess the location information
      3. <external ruleset>: This field contains a URI that indicates where a fuller ruleset of policies, related to this object, can be found
      4. <notewell>: This field contains a block of text containing further generic privacy directives.
   3. <method> is an optional element that describes the way that the location information was derived or discovered. Values allowed by RFC 4119 [37] are stored in the IANA registry as “Method Tokens” [17]. The “Wiremap” value listed in the example is described as “Location determined using wiremap correlations to circuit identifiers”

4. <deviceID> element is mandatory. It contains a globally unique identifier, in the form of a URN, for each of the presentity devices (RFC 4479 [44])

5. <timestamp> is optional (RFC 4479 [44])

XVIII.3.3 Use of RFC 5491 and RFC 5139 Location XML Elements in CWMP or USP

1. <presence>
   The entity attribute conveys no useful information and its value should be conventionally set to an empty string.

2. <device>
   In RFC 5491 [50] this is one of the devices associated to the presentity. Devices are identified in the presence document by means of an instance identifier specified in the id attribute.

3. <geopriv>

   1. <location-info>
      2-D geographical coordinates with no additional civic information are sufficient in the simplest case.
      • <Point>
        For 2-D applications the value of the srsName attribute should be set to the specified value “urn:ogc:def:crs:EPSG::4326”
   2. <usage-rules>
      • <retransmission-allowed>
        Note that this field is not intended as instruction to the device whose location this is. Rather, it is intended to provide instruction to other systems that the device sends its location to (via SIP or other mechanisms). Therefore, the device will need to maintain its own policy (no standardized TR-069 data model is provided for this) as to when and where to send its location to others, and how to set this parameter when transmitting this location information. The device can choose to set this parameter to “yes” or to “no” when sending its location to others. RFC 4119 [37] specifies that this element’s default value is “no”.
   3. <method>
      If this location object is being created by the device as a result of GPS, A-GPS, or Manual mechanisms, the <method> parameter will be populated with “GPS”, “A-GPS”, or “Manual”, respectively. If the location object is being created by External:CWMP, then this parameter will not be used or populated by the Controller.

4. <deviceID> It contains a globally unique identifier, in the form of a URN, for each of the presentity devices (RFC 4479 [44]).

5. <timestamp> is optional. The device (GPS, A-GPS, Manual), ACS (External:CWMP) or USP-Controller (External:USP) can set this to the time the location was set or acquired.

Appendix XIX: Fault Management

This section discusses the Theory of Operation for Fault Management using CWMP [2] or USP [11] and the FaultMgmt object defined in the Root data model.

XIX.1 Overview

There are four types of alarm event handling:

Note that all Fault Management tables are cleared when the device reboots.

Table 16 shows the multi-instance objects for FM to manage the alarm events.

Appendix XX: BASAPM and LMAP Theory of Operation

Broadband Access Service Attributes and Performance Metrics (BASAPM) and Large-Scale Measurement of Broadband Performance (LMAP) data model components are derived from TR-304 [10] and the IETF LMAP information model [65], respectively.

XX.1 TR-069 Family of Specifications in the Context of TR-304

This section describes possible deployment scenarios where the CWMP and IPDR protocols are used for the respective TR-304 protocols.

XX.1.1 TR-304 and IETF LMAP Frameworks

The IETF (LMAP) and BBF (TR-304) use a similar framework for diagnostics where each framework consists of a Measurement Controller, Data Collector and Measurement Agent. While there are differences between TR-304 and LMAP elements in various deployment scenarios, in residential scenarios the behavior of Measurement Agent in the home is consistent between the IETF LMAP and BBF TR-304 frameworks.

XX.1.1.1 TR-304 Framework

The TR-304 framework consists of a Management Server that is used to manage and configure the Measurement Agent. This would also include receiving logging and status information as well as the capability to schedule the Measurement Agent for tests. The TR-304 framework also has a Measurement Controller with the responsibility to schedule the Measurement Agent for tests to be performed provide test admin control. TR-304 framework also has multiple channels where a Measurement Agent can send reports to the different Data Collectors.

XX.1.1.2 IETF LMAP Framework

The IETF LMAP framework, like the BBF TR-304 framework, consists of a Management Server that is used to pre-configure the Measurement Agent. Note that this also could be done at the manufacturing stage of the device. The LMAP framework also has a Measurement Controller with the responsibility to configure the Measurement Agent for tests to be performed; provide instructions about the test and receive status and logging information the Measurement agents. In the IETF LMAP framework these functions are treated as individual channels that can be assigned to different Measurement Controllers. Likewise the Reporting interface also has multiple channels where a Measurement Agent can send reports to the different Data Collectors.

XX.1.2 CWMP for Pre-configuration

In the IETF LMAP and TR-304 frameworks, CWMP can be used to pre-configure the Measurement Agent; where the Controller and Data Collector could use other protocols (e.g., IETF LMAP protocol).

Note that in the TR-304 framework the Status and Logging functions have not been explicitly identified as capabilities of the Controller.

XX.1.3 CWMP for Control and Pre-configuration, IPDR for Reporting

In the IETF LMAP and TR-304 frameworks, CWMP can be used to pre-configure the Measurement Agent and manage/schedule the tests. Likewise the IPDR protocol can be used to report the test results. In this scenario, the ACS would act as the Management Server and Measurement Controller. This scenario would place a constraint on the IETF LMAP framework in that there would be allowed only 1 Measurement Controller per Measurement Agent. See Bulk Data Collection in the Context of LMAP for additional information on use of the BulkData.Profile object in the context of LMAP.

XX.1.4 CWMP as a Proxier, IPDR for Reporting

In scenarios where Measurement Agent does not have connectivity with the Measurement Controller, CWMP can be used to act as a proxy between the Measurement Controller and Measurement Agent. In this scenario, if the CWMP Proxy is an Embedded Device then both Measurement Agents are associated with the same ACS. If the Measurement Agents need to be associated with different Measurement Controllers then the CWMP Virtual Device mechanism is to be used.

XX.1.5 Multi-ACS Deployment

In the IETF LMAP framework, the Measurement Agent could interact with different elements that implement the functionality of the Management Server and Measurement Controller. In addition, the IETF LMAP framework also permits the functionality of the Measurement Controller to be implemented in multiple elements.

For a CWMP framework, this would require a different CWMP Agent for each application. As such this type of scenario is not realistically supported by CWMP.

XX.2 Derivation of Data Model Elements

XX.2.1 Device.BASAPM

Device.BASAPM provides a TR-304 [10] wrapper for a Device.LMAP. MeasurementAgent instance. Device.BASAPM provides parameters related to the operational domain, device ownership, device identification, geographic location, and measurement reference point of a referenced Device.LMAP.MeasurementAgent instance.

XX.2.2 Device.LMAP.MeasurementAgent

The Device.LMAP objects and parameters are mostly described in the IETF LMAP information model [65]. That document serves as the primary vehicle for describing theory of operations for Device.LMAP.MeasurementAgent.

The base Device.LMAP.MeasurementAgent.{i} object contains parameters defined in LMAP information model ma-config-obj, ma-status-obj, and ma-capability-obj. The ma-preconfig-obj parameters are not modeled in Device:2 data model , because there is no need for pre-configuration values in a CWMP/USP-managed Measurement Agent. The information model parameters map to Device:2 data model parameters as shown in Table 17:

All of the other IETF LMAP information model parameters can be readily mapped to objects and parameters in Device.LMAP.MeasurementAgent.{i}.

XX.3 Bulk Data Collection in the Context of LMAP

The TR-069 family of specifications has defined protocols that can be used for the collection of bulk data between a CWMP Agent and an ACS. These protocols are defined for IPDR [9] and HTTP [2]. The Device:2 data model described in Derivation of Data Model Elements includes the ability to use these protocols for transferring test results between a Measurement Agent and a Data Collector.

When integrating the test results of the Device:2 data model (i.e., LMAP.Report object instance) into the bulk data objects and parameters provided by the Device:2 data model, the LMAP.Report object instance becomes the referenced parameter of the Bulk Data Profile (BulkData.Profile object instance). In addition, there is a linkage needed within the LMAP data model to identify the BulkData.Profile object instance. This is done through the reference of the BulkData.Profile object instance from the LMAP data model’s Communication Channel for a Scheduled Action.

XX.4 TR-143 Diagnostics in LMAP

TR-143 [6] describes a set of tests that can be used within the context of TR-304 based on the IETF LMAP framework [60] and Information Model [65] and implemented using the Device:2 data model in Derivation of Data Model Elements. These tests could be defined using the following procedure:

1. The TR-143 diagnostic needs to be identified as a URI in the registry entry (Device.LMAP.MeasurementAgent.{i}.TaskCapability.{i}.Registry.{i}.RegistryEntry):
   • The URI is in the form of: urn:bbf:lmap:<BBF TR>:<DiagnosticProfileName>
   • For example a TR-143 upload diagnostic could be: “urn:bbf:lmap:tr-181-2-11-0:UploadDiagnostics-1”
2. The TR-143 diagnostic’s parameters and objects that are modifiable by the Controller/Measurement Controller are encoded in the Device.LMAP.MeasurementAgent.{i}.Task.{i}.Option.{i}. or Device.LMAP.MeasurementAgent.{i}.Schedule.{i}.Action.{i}.Option.{i} objects.
   • For example: Device.IP.Diagnostics.UploadDiagnostics.DiagnosticsState=requested
3. The TR-143 diagnostic’s parameters and objects that are read-only are encoded in the Device.LMAP.Report.{i}.Task.{i}.Result.{i}.Values where each parameter name is encoded in the Device.LMAP.Report.{i}.Task.{i}.ColumnLabels parameter.
   • For example:
     ColumnLabels:
     Device.IP.Diagnostics.UploadDiagnostics.PerConnectionResult.{1}.TotalBytesSent
   • Value: 30

Appendix XXI: 5G Theory of Operation

This section discusses the Theory of Operation for 5G Wireline Wireless Convergence using CWMP or USP and the supporting Device.WWC, Device.SessionManagement.PDU and Device.FWE objects.

XXI.1 Overview

A 5G-RG brings with it a completely different way of operation. This is a direct consequence of features such as:

• Control User Plane Separation (CUPS)
• Multiple IP sessions over a PHY
• 5G QoS
• Hybrid Access (Fixed and Cellular)
• Network Slicing

The above features are supported by the TR-181 data model using new data model elements comprising:

• Interface stack layer to support 5G Fixed Encapsulation (5WE)
• Objects to describe registration and session management.
• Integration with existing TR-181 elements

XXI.2 Architecture

The 5G converged core represents a significant departure from the TR-101 [3] based architecture currently used to support residential gateway access. Most noteworthy is the alignment with 3GPP architectural principles. It is important to understand the two deployment scenarios for the 5G core—Integration and Interworking.

Integration – All wireline traffic transits the AGF (Access Gateway Function) before entering the 3GPP-defined 5G core. Both 5G-RGs and FN-RGs may use the AGF natively. In the case of a 5G-RG, the AGF will support 5G NAS and PDU (multiple IP sessions) transport. Whilst a FN-RG is limited to TR-101 and the NAS and PDU (single IP session) is emulated by the AGF on behalf of the FN-RG, RGs may use wireline, wireless or both access networks. However, in the case of multiple access networks, all must use 5G NAS + PDU if ATSSS is to be supported.

Interworking – All wireline traffic uses the current TR-101-based solutions (BNG + AAA). The FMIF emulates all the TR-101 control plane functions needed by the BNG and converts to 5G NAS. Current thinking is that user plane traffic will continue to be handled by the BNG. Note: A 5G-RG reverts to FN-RG mode when connected to a BNG. The interworking scenario is based around a standard FN-RG and has zero impact on the TR-181 data model

In the diagram below the elements in green, namely 5G-RG, AGF and FMIF, are BBF-defined.

The complete 5G architecture is documented in the 3GPP 23.501 [14] standard. BBF has produced TR-470 [12] documenting the Wireline Wireless Convergence architecture. Shown below is a simplified architecture with the network functions and interfaces relevant to supporting a 5G-RG.

XXI.2.1 Network Functions

XXI.3 Concepts

XXI.3.1 Control User Plane Separation (CUPS)

CUPS is integral to the entire 5G architecture. It starts with the segregation of control and user plane traffic at the 5G-RG and continues through to the physical separation of control and user plane network functions. The main driver for separation is to centralize control plane functions whilst distributing user plane functions deeper into the network. CUPS is documented in TR-470 Section 5.2 [12] whilst TS 23.501 [14] details the architectural elements. From the perspective of a 5G-RG, CUPS has the following impacts:

• Control plane communications move from transient (DHCP and PPP LCP ) to persistent (NAS). As a result, the operator can now modify a customer session at any time rather than at the point of authorization.
• Traffic for control and user planes uses separate sessions over a common PHY.
• DHCP and DHCPv6 technically move from the control to the user plane (UPF responsibility). However, both protocols can and need to be used to deliver configuration via their options.

XXI.3.2 Policy

One of the new design principles brought by 5G to the residential gateway is that of policy. Previous generations of mobile devices have been users of policy but 5G takes it to a new level. Policy and the role of the PCF are documented in TS 23.503 [13].

So, what is policy?
The simplest way to think of policy is as a set of per-service rules sent to the 5G-RG by the network operator. This allows the operator to dynamically control how a 5G-RG connects to a 5G network in terms of network slices, data networks and QoS with application level granularity.

How is it delivered?
Policy is managed by the Policy Control Function (PCF), which provides policy in two distinct phases. At the time of registration, a routing policy table (URSP) is provided upon successful authentication. When a PDU session is created, URSP provides the necessary network slice and data network information. The second phase of policy is learnt upon successful PDU creation, where a set of QoS rules is provided.

XXI.3.3 Multiple PDU sessions

One of the more significant features of a 5G-RG is the support of multiple PDU sessions. Each PDU can be considered to be a virtual circuit between a 5G-RG and a UPF instance. A PDU instance can be assigned IP addresses, QoS rules and even guaranteed bit rates. This leads to applications requiring:

• Separate IP sessions.
• Preferential data paths within the operator’s network.
• Traffic separation for security.
• Guaranteed bit rates for a given application.

TR-470 Section 6.2 [12] provides examples of multiple PDU scenarios for a 5G-RG.

XXI.3.4 5G QoS

Unlike the more familiar QoS markings such as DSCP or Ethernet priority, 5G QoS marking is merely a label called a QoS Flow Indicator (QFI). End-to-end QoS as documented in TR-470 Section 5.1 [12] is a key outcome of policy. As part of PDU establishment, a set of QoS rules is supplied specific to that PDU. Consequently, the access network specifies not only the supported QFI labels but also the properties of the QoS profile. A QoS profile consists of the following properties:

• 5G QoS Identifier (5QI). Unlike a QFI, 5QI does have a defined set of properties such as priority and whether its bit rate is guaranteed.
• Allocation and Retention Policy (ARP).
• For Guaranteed Bit Rate (GBR) profiles the guaranteed and maximum upload and download bit rates.
• GBR profiles may also specify a maximum packet loss.

XXI.3.5 Data Network Name (DNN)

One of the benefits of multiple PDU sessions is the ability to have preferred data paths within the network. A 5G core achieves this using DNNs mapped to dedicated UPFs. A DNN is always specified when establishing a PDU and the 5G-RG learns the preferred DNN through URSP policy.

XXI.3.6 Multiple Access Networks

Whilst FN-RGs are perfectly capable of supporting multiple access networks, each access network operates independently with separate IP addresses and an inability to seamlessly switch traffic between them. A 5G-RG can modify a PDU and switch traffic to another supported access network and maintain all the PDU properties including IP addresses. An operator can optimize its network usage by sending policy rules to a 5G-RG, indicating the preferred access and data networks. TR-470 Section 4.4 [12] provides a more in-depth description of hybrid access.

XXI.3.7 Network Slicing

An operator may choose to partition their network infrastructure for the purposes of resiliency or merely to optimize for a particular function such as IoT. Each instance of the partitioned network is called a network slice. Operators will provide slice information as part of URSP policy rules. Every PDU at the time of establishment must specify a network slice. Slicing is further documented in TS 23.501 Clause 5.15 [14].

XXI.4 Data Model Elements

XXI.4.1 Interface Stack

User plane traffic on a 5G-RG is carried as part of a PDU session carrying L3 traffic (usually IPv4 or IPv6). Whilst cellular networks have native methods for separating PDU traffic, fixed access networks do not. Operators have a choice of two multiplexing strategies, both of which require co-ordination between the 5G-RG and AGF:

• VLAN: Each PDU uses a separate VLAN with the VLAN id as the session identifier.
• 5WE: An encapsulation method designed to carry multiplexed PDU traffic over existing (non 5G) access networks [66].

The OSI layer model (see Figure 10) now has 5WE (Device.FWE.Link in the model) at ‘L2---’ and the previous ‘L2--’ pushed down to ‘L2---’.

XXI.4.1.1 Scenario #1 - Fixed access network only

This example shows two PDU sessions using a VDSL access network. As this is a fixed service, the 5WE protocol is used to multiplex the PDU traffic over the VDSL service. NAS traffic is separate from the PDU traffic and is carried as PPPoE over the VDSL service. All LAN traffic remains unchanged on a 5G-RG.

XXI.4.1.2 Scenario #2 - Cellular access network only

This example shows two PDU sessions using a cellular access network. In this case the 5G-RG does not to need to multiplex the PDU traffic as the cellular module handles that internally. NAS traffic does not appear in this diagram as the requests are made directly to the cellular module. Depending on the cellular module, each PDU may need to be carried over a VLAN (this has been omitted for the moment). All LAN traffic remains unchanged on a 5G-RG.

XXI.4.1.3 Scenario #3 - Hybrid (Fixed and Cellular) access

This example shows two PDU sessions using both VDSL and cellular access networks. Either access network is capable for carrying either PDU or both. A PDU in this situation can only be carried on a single access network at a time. Fixed traffic is multiplexed using 5WE (even if only one PDU is present) whilst PDU traffic to the cellular network is multiplexed by the cellular module. NAS traffic using the PPP interface is for the fixed component only as cellular requests are made directly to the cellular module. Depending on the cellular module, each PDU may need to be carried over a VLAN (this has been omitted for the moment). All LAN traffic remains unchanged on a 5G-RG.

XXI.4.2 Data Model

XXI.4.2.1 Device.WWC

The relationship between a 5G-RG and the available access networks is represented by the Device.WWC object tree. All objects are read only and are intended for service assurance purposes.

XXI.4.2.2 Device.SessionManagement.PDU

The logical connection between the 5G-RG and data network is the Protocol Data Unit (PDU). The Device.SessionManagement.PDU subtree describes each PDU session’s properties together with the QoS rules specific to that PDU session.

XXI.4.2.3 Device.FWE

5G Wireless Wireline Convergence User Plane Encapsulation [66] is used to separate each PDU session when multiplexed over a PHY. A Device.FWE.Link object is inserted into the interface stack, providing PDU session id as well as 5G QoS markings (QFI, RQI). This is also the level at which fixed QoS rules are applied in order to traverse access networks that do not natively support 5G QoS (QFI) markings. An instance of this object will be created by a 5G-RG whenever a PDU is established.

XXI.4.3 Examples

Each example shows a 5G-RG with two PDU sessions. The first is for general purpose internet traffic and the second for IMS VoIP. Each PDU session has a default QoS rule matching the intended use. The general internet PDU also has rule to mark VoWiFi traffic with the same QFI as IMS traffic.

XXI.4.3.1 Scenario #1 - Fixed access network only

Device.WWC.
    Capabilities = "FN-RG,5G-RG,W-5GAN"
    Mode = "5G-RG"
    Status = "5G-RG"
    AccessNetworkNumberOfEntries = 1
    URSPNumberOfEntries = 2
Device.WWC.AccessNetwork.1.
    Alias = "cpe-fixed"
    Name = "fixed"
    Interface = Device.Ethernet.5
    RegistrationStatus = "RM-REGISTERED"
    ConnectionStatus = "CM_CONNECTED"
    AccessNetworkType = "W-5GAN"
Device.WWC.AccessNetwork.1.GUTI
    PLMN = 50501
    AMFid = 65601
    TMSI = 60340039
Device.WWC.URSP.1.          # Default traffic rule
    Alias = "cpe-ursp1"
    Precedence = 100
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.
    Alias = "cpe-ursp11"
    Type = 1                # Match all traffic
    Value = ""
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp111"
    Precedence = 100
    SSC = 1
    DNN = "provider.internet"
    PDUSessionType = "IPv4v6"
    AccessType = "Non-3GPP access"
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.WWC.URSP.2.           # VoUP traffic rule
    Alias = "cpe-ursp2"
    Precedence = 10
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.
    Alias = "cpe-ursp21"
    Type = 144               # Connection Capability Type
    Value = "1"              # IMS
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp211"
    Precedence = 100
    SSC = 1
    DNN = "provider.ims"
    PDUSessionType = "IPv6"
    AccessType = "Non-3GPP access"
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.SessionManagement.
    SessionNumberOfEntries = 2
    PDUNumberOfEntries = 2
Device.SessionManagement.Session.1.
    Alias = "cpe-session1"
    SessionId = 1
    Reference = Device.SessionManagement.PDU.1.
    Interface = Device.IP.Interface.1.
    APN = "provider.internet"
Device.SessionManagement.PDU.1.
    Alias = "cpe-pdu1"
    PTI = 63
    SSC = 1
    SessionAMBRDownlink = 100000000
    SessionAMBRUplink = 40000000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 2
Device.SessionManagement.Session.1.PCO
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
Device.SessionManagement.PDU.1.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.1.QoSRule.1.
    Alias = "cpe-pdu11"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 1
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.1.Filter.1.
    Alias = "cpe-pdu111"
    Direction = "bidirectional"
    Type = 1                  # Match all
Device.SessionManagement.PDU.1.QoSRule.2.
    Alias = "cpe-pdu12"
    Identifier = 2
    Precedence = 10
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.2.Filter.1.
    Alias = "cpe-pdu121"
    Direction = "bidirectional"
    Type = 33                  # Destination IPv6
    Value = "2001:db8::2:1"    # VoWiFi ePDG
Device.SessionManagement.PDU.1.QoSFlow.1.
    Alias = "cpe-pdu11"
    QFI = 1
    FiveQI = 8
Device.SessionManagement.PDU.1.QoSFlow.2.
    Alias = "cpe-pdu11"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000
Device.SessionManagement.Session.2.
    Alias = "cpe-session2"
    SessionId = 6
    Reference = Device.SessionManagement.PDU.2.
    Interface = Device.IP.Interface.2
    APN = "provider.ims"
Device.SessionManagement.PDU.2.
    Alias = "cpe-pdu2"
    PTI = 34
    SSC = 1
    SessionAMBRDownlink = 150000
    SessionAMBRUplink = 150000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 1
Device.SessionManagement.Session.2.PCO
    IPv6PCSCF = "2001:db8::1:1"
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
    IPv4PCSCF = "203.0.113.100"
Device.SessionManagement.PDU.2.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.2.QoSRule.1.
    Alias = "cpe-pdu21"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.2.QoSRule.1.Filter.1.
    Alias = "cpe-pdu211"
    Direction = "bidirectional"
    Type = 1            # Match all
Device.SessionManagement.PDU.2.QoSFlow.1.
    Alias = "cpe-pdu21"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000
Device.FWE.
    LinkNumberOfEntries
Device.FWE.Link.1.
    Alias = "cpe-fwe1"
    Name = "cpe-fwe1"
    Status = "Up"
    LowerLayers = "Device.Ethernet.5"
Device.FWE.Link,1,Stats
    BytesSent = 478945789
    BytesReceived = 589545478

XXI.4.3.2 Scenario #2 - Cellular access network only

Device.WWC.
    Capabilities = "FN-RG,5G-RG,NG-RAN,E-UTRAN"
    Mode = "5G-RG"
    Status = "5G-RG"
    AccessNetworkNumberOfEntries = 1
    URSPNumberOfEntries = 2
Device.WWC.AccessNetwork.1.
    Alias = "cpe-cellular"
    Name = "cellular"
    Interface = Device.Cellular.Interface.1
    RegistrationStatus = "RM-REGISTERED"
    ConnectionStatus = "CM_CONNECTED"
    AccessNetworkType = "NG-RAN"
Device.WWC.AccessNetwork.1.GUTI
    PLMN = 50501
    AMFid = 131137
    TMSI = 54678959
Device.WWC.URSP.1.             # Default traffic rule
    Alias = "cpe-ursp1"
    Precedence = 100
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.
    Alias = "cpe-ursp11"
    Type = 1                   # Match all traffic
    Value = ""
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp111"
    Precedence = 100
    SSC = 1
    DNN = "provider.internet"
    PDUSessionType = "IPv4v6"
    AccessType = "3GPP access"
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.WWC.URSP.2.             # VoUP traffic rule
    Alias = "cpe-ursp2"
    Precedence = 10
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.
    Alias = "cpe-ursp21"
    Type = 144                 # Connection Capability Type
    Value = "1"                # IMS
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp211"
    Precedence = 100
    SSC = 1
    DNN = "provider.ims"
    PDUSessionType = "IPv6"
    AccessType = "3GPP access"
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.SessionManagement.
    SessionNumberOfEntries = 2
    PDUNumberOfEntries = 2
Device.SessionManagement.Session.1.
    Alias = "cpe-session1"
    SessionId = 1
    Reference = Device.SessionManagement.PDU.1.
    Interface = Device.IP.Interface.1.
    APN = "provider.internet"
Device.SessionManagement.PDU.1.
    Alias = "cpe-pdu1"
    PTI = 63
    SSC = 1
    SessionAMBRDownlink = 100000000
    SessionAMBRUplink = 40000000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 2
Device.SessionManagement.Session.1.PCO
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
Device.SessionManagement.PDU.1.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.1.QoSRule.1.
    Alias = "cpe-pdu11"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 1
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.1.Filter.1.
    Alias = "cpe-pdu111"
    Direction = "bidirectional"
    Type = 1                   # Match all
Device.SessionManagement.PDU.1.QoSRule.2.
    Alias = "cpe-pdu12"
    Identifier = 2
    Precedence = 10
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.2.Filter.1.
    Alias = "cpe-pdu121"
    Direction = "bidirectional"
    Type = 33                  # Destination IPv6
    Value = "2001:db8::2:1"    # VoWiFi ePDG
Device.SessionManagement.PDU.1.QoSFlow.1.
    Alias = "cpe-pdu11"
    QFI = 1
    FiveQI = 8
Device.SessionManagement.PDU.1.QoSFlow.2.
    Alias = "cpe-pdu11"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000
Device.SessionManagement.Session.2.
    Alias = "cpe-session2"
    SessionId = 6
    Reference = Device.SessionManagement.PDU.2.
    Interface = Device.IP.Interface.2.
    APN = "provider.ims"
Device.SessionManagement.PDU.2.
    Alias = "cpe-pdu2"
    PTI = 34
    SSC = 1
    SessionAMBRDownlink = 150000
    SessionAMBRUplink = 150000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 1
Device.SessionManagement.Session.2.PCO
    IPv6PCSCF = "2001:db8::1:1"
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
    IPv4PCSCF = "203.0.113.100"
Device.SessionManagement.PDU.2.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.2.QoSRule.1.
    Alias = "cpe-pdu21"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.2.QoSRule.1.Filter.1.
    Alias = "cpe-pdu211"
    Direction = "bidirectional"
    Type = 1            # Match all
Device.SessionManagement.PDU.2.QoSFlow.1.
    Alias = "cpe-pdu21"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000

XXI.4.3.3 Scenario #3 - Hybrid (Fixed and Cellular) access

Device.WWC.
    Capabilities = "FN-RG,5G-RG,W-5GAN"
    Mode = "5G-RG"
    Status = "5G-RG"
    AccessNetworkNumberOfEntries = 2
    URSPNumberOfEntries = 2
Device.WWC.AccessNetwork.1.
    Alias = "cpe-fixed"
    Name = "fixed"
    Interface = Device.Ethernet.5
    RegistrationStatus = "RM-REGISTERED"
    ConnectionStatus = "CM_CONNECTED"
    AccessNetworkType = "W-5GAN"
Device.WWC.AccessNetwork.1.GUTI
    PLMN = 50501
    AMFid = 65601
    TMSI = 60340039
Device.WWC.AccessNetwork.2.
    Alias = "cpe-cellular"
    Name = "cellular"
    Interface = Device.Cellular.Interface.1
    RegistrationStatus = "RM-REGISTERED"
    ConnectionStatus = "CM_CONNECTED"
    AccessNetworkType = "NG-RAN"
Device.WWC.AccessNetwork.2.GUTI
    PLMN = 50501
    AMFid = 131137
    TMSI = 54678959
Device.WWC.URSP.1.             # Default traffic rule
    Alias = "cpe-ursp1"
    Precedence = 100
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.
    Alias = "cpe-ursp11"
    Type = 1                   # Match all traffic
    Value = ""
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp111"
    Precedence = 100
    SSC = 1
    DNN = "provider.internet"
    PDUSessionType = "IPv4v6"
    AccessType = "Non-3GPP access"
Device.WWC.URSP.1.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.WWC.URSP.2.             # VoUP traffic rule
    Alias = "cpe-ursp2"
    Precedence = 10
    TrafficDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.
    Alias = "cpe-ursp21"
    Type = 144                 # Connection Capability Type
    Value = "1"                # IMS
    RouteSelectionDescriptorNumberOfEntries = 1
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.
    Alias = "cpe-ursp211"
    Precedence = 100
    SSC = 1
    DNN = "provider.ims"
    PDUSessionType = "IPv6"
    AccessType = "Non-3GPP access"
Device.WWC.URSP.2.TrafficDescriptor.1.RouteSelectionDescriptor.1.NetworkSlice
    SliceServiceType = "eMBB"
Device.SessionManagement.
    SessionNumberOfEntries = 2
    PDUNumberOfEntries = 2
Device.SessionManagement.Session.1.
    Alias = "cpe-session1"
    SessionId = 1
    Reference = Device.SessionManagement.PDU.1.
    Interface = Device.IP.Interface.1.
    APN = "provider.internet"
Device.SessionManagement.PDU.1.
    Alias = "cpe-pdu1"
    PTI = 63
    SSC = 1
    SessionAMBRDownlink = 100000000
    SessionAMBRUplink = 40000000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 2
Device.SessionManagement.Session.1.PCO
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
Device.SessionManagement.PDU.1.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.1.QoSRule.1.
    Alias = "cpe-pdu11"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 1
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.1.Filter.1.
    Alias = "cpe-pdu111"
    Direction = "bidirectional"
    Type = 1                   # Match all
Device.SessionManagement.PDU.1.QoSRule.2.
    Alias = "cpe-pdu12"
    Identifier = 2
    Precedence = 10
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.1.QoSRule.2.Filter.1.
    Alias = "cpe-pdu121"
    Direction = "bidirectional"
    Type = 33                  # Destination IPv6
    Value = "2001:db8::2:1"    # VoWiFi ePDG
Device.SessionManagement.PDU.1.QoSFlow.1.
    Alias = "cpe-pdu11"
    QFI = 1
    FiveQI = 8
Device.SessionManagement.PDU..1.QoSFlow.2.
    Alias = "cpe-pdu11"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000
Device.SessionManagement.Session.2.
    Alias = "cpe-session2"
    SessionId = 6
    Reference = Device.SessionManagement.PDU.2.
    Interface = Device.IP.Interface.2.
    APN = "provider.ims"
Device.SessionManagement.PDU.2.
    Alias = "cpe-pdu2"
    PTI = 34
    SSC = 1
    SessionAMBRDownlink = 150000
    SessionAMBRUplink = 150000
    QoSRuleNumberOfEntries = 2
    QoSFlowNumberOfEntries = 1
Device.SessionManagement.Session.2.PCO
    IPv6PCSCF = "2001:db8::1:1"
    IPv6DNS = "2001:db8::1,2001:db8::2"
    IPv4DNS = "203.0.113.1,203.0.113.2"
    IPv4PCSCF = "203.0.113.100"
Device.SessionManagement.PDU.2.NetworkSlice
    SliceServiceType = "eMBB"
    SliceDifferentiator = 4
Device.SessionManagement.PDU.2.QoSRule.1.
    Alias = "cpe-pdu21"
    Identifier = 1
    Precedence = 100
    Segregation = false
    QFI = 32
    DQR = true
    FilterNumberOfEntries = 1
Device.SessionManagement.PDU.2.QoSRule.1.Filter.1.
    Alias = "cpe-pdu211"
    Direction = "bidirectional"
    Type = 1            # Match all
Device.SessionManagement.PDU.2.QoSFlow.1.
    Alias = "cpe-pdu21"
    QFI = 32
    FiveQI = 1
    GFBRUplink = 150000
    GFBRDownlink = 150000
Device.FWE.
    LinkNumberOfEntries
Device.FWE.Link.1.
    Alias = "cpe-fwe1"
    Name = "cpe-fwe1"
    Status = "Up"
    LowerLayers = Device.Ethernet.5
Device.FWE.Link,1,Stats
    BytesSent = 478945789
    BytesReceived = 589545478

Appendix XXII: Data Elements Theory of Operations

The contents of this Appendix has moved to Appendix III.9.

Appendix XXIII: Logical Interfaces Theory of Operations

XXIII.1 Introduction

The intention of the logical interface concept is to simplify the configuration management of individual TR-181 services. Instead of configuring the individual network service with a physical or IP interface and dealing with reconfiguration problems that can occur during auto detection of WAN interfaces, the network interface can be configured with a logical interface. This allows the configuration of the network service to stay unchanged when switching between WAN interfaces. The software service responsible for managing WAN interface changes then only needs to care about rewriting the LowerLayers parameter of the LogicalInterface Objects.

XXIII.2 Concept

The idea of the logical interface is that it represents simple arbitrary concepts such as:

• lan -> the LAN bridge interface
• wan -> the WAN interface
• data -> interface to send data traffic (can be seen as a wan too)
• iptv -> interface used for only IPTV traffic
• voip -> interface used only for VoIP traffic
• mgmt -> interface used only for management traffic

Traditionally a network service such as a time server is configured by pointing Time.Server.{i}.Interface. to a Device.IP.Interface.{i} object.

Now with logical interfaces, these types of services can be configured by using a Logical Interface instead of using an IP interface. For example:

Time.Server.{i}.Interface = Device.Logical.Interface.1.

And Device.Logical.Interface.1. would in this example be the WAN interface. And its LowerLayers parameter would be pointing to a stackable IP interface

XXIII.3 WAN mode changes

Requirement IF.WAN.ETH of TR-124 describes at a high-level what an internal service responsible for detecting the correct WAN interface must do. The logical interface concept avoids the need for a WAN mode manager that must be aware of all the specificities of the internal network services.

Logical interfaces significantly reduce the complexity of the WAN mode manager. Without it the WAN mode manager needs to be aware of all the network services, and how to configure them and maybe trigger a restart. By using the concept of the logical interfaces, the WAN mode manager only needs to reconfigure the network stack, and update the LowerLayers parameter of the logical interfaces.

Each individual internal network service must subscribe to the interface status updates.

When the interface is disabled and re-enabled, it is the responsibility of the internal service to retrieve the new lower interface and the associated IP address.

XXIII.4 How to use

A logical interface can be used on top of one or more stackable interfaces. IPv4 and IPv6 on a different network interface is an example where a logical interface is layered on top of multiple IP interfaces. Most of the time a logical interface will just be layered on top of one IP interface. In theory a logical interface could be layered anywhere in the interface stack topology.

When a logical interface is used for configuring an Interface parameter, the logical interface will inherit the parameter type that has been declared in the data model. Meaning when the expected parameter type is IP.Interface the logical interface must resolve to an existing IP.Interface.

Device.SSH.Server.2.Interface = "Device.Logical.Interface.1."

XXIII.5 Examples

XXIII.5.1 Tagged - untagged Ethernet switching

In this example the WAN mode manager decides to switch the network configuration from an untagged Ethernet traffic configuration to a tagged Ethernet configuration. This is a similar problem to when the WAN mode manager decides to switch between mono VC and a multi VC xDSL configuration.

XXIII.5.1.1 Untagged Ethernet configuration

XXIII.5.1.2 Tagged Ethernet configuration

By using the logical interface method, it is not necessary any more to update the configuration of the time server when the WAN mode manager switches between a tagged and untagged WAN mode.

XXIII.5.2 IPv4 and IPv6 on a different network interface

In this example the Time server needs to use the IPv4 and IPv6 addresses of the WAN interfaces. In more traditional scenarios the IPv4 and IPv6 addresses are available on the same network interface, but in this example the IPv4 and IPv6 addresses are on different network interfaces.

With the help of the Logical Interface, the Time server can automatically retrieve the correct IPv4 or IPv6 address from the TR-181 data model without having to know all the details that come from a certain WAN mode or network configuration.

Appendix XXIV: MTU configuration Theory of Operations

XXIV.1 Introduction - Understanding MTU in Layer 2 and Layer 3 Networks

The Maximum Transmission Unit (MTU) defines the maximum size of data packets that can be transmitted across a network segment without fragmentation. MTU values are crucial for efficient data transmissions.

Two layers where MTU considerations are paramount are Layer 2 (Data Link Layer) and Layer 3 (Network Layer). Ethernet MTU, fundamental to Layer 2 networks, determines the maximum payload size within Ethernet frames. In contrast, IP MTU, governing Layer 3, defines the maximum size of IP packets, including headers and payloads. While both share a standard size of 1500 bytes.

Typically the Layer 2 and Layer 3 is set to 1500 bytes.

XXIV.2 Use cases

Dynamic MTU Assignment: An upstream DHCP server may include MTU information in DHCP lease offers. When the Device or Gateway requests an IP address lease from the DHCP server, along with the IP address, subnet mask, default gateway, DNS server information, the DHCP server also provides the MTU size.

Jumbo Frames Support: Some network devices and applications support jumbo frames, which are frames with an MTU larger than the standard Ethernet MTU of 1500 bytes. Enabling jumbo frames by increasing the MTU size can improve throughput and reduce CPU overhead on networking equipment, particularly in high-performance computing environments.

Avoiding Fragmentation: In networks where packet fragmentation occurs frequently due to mismatched MTU sizes between different network segments, adjusting the MTU to a common size can help avoid fragmentation. Fragmentation can degrade performance and increase the processing overhead on routers and switches.

XXIV.3 Interface example

XXIV.4 Simple Linux bridge example

Appendix XXV: 3GPP NAS Theory of Operation

This section discusses the Theory of Operation for RGs using 3GPP NAS signalling. This includes both the cellular and 5G fixed interfaces using CWMP or USP and the supporting Device.Cellular and Device.SessionManagement objects.

XXV.1 Overview

The addition of a cellular interface to a residential gateway has become more commonplace in recent years. In particular, hybrid and Fixed Wireless Access (FWA) devices are increasingly offered by service providers. With increased usage comes a more diverse set of use cases, all of which drive the need for a set of cellular objects better aligned with the overall TR-181 model.

An RG utilizing interfaces with NAS signalling brings with it a completely different way of operation. This is a direct consequence of features such as:

• Control User Plane Separation (CUPS)
• Multiple IP sessions over a PHY
• 3GPP QoS
• Hybrid Access (Fixed and Cellular)
• Network Slicing

The above features are supported by the TR-181 data model using new data model elements comprising:

• Interface stack layer to support 5G Fixed Encapsulation (5WE)
• Objects to describe registration and session management.
• Integration with existing TR-181 elements

XXV.2 Concepts

XXV.2.1 3GPP Generations - 2, 3, 4 and 5G

XXV.2.2 Control User Plane Separation (CUPS) - 4G and 5G

CUPS is integral to the 4G and 5G architectures. It starts with the segregation of control and user plane traffic at the RG and continues through to the physical separation of control and user plane network functions. The main driver for separation is to centralize control plane functions while distributing user plane functions deeper into the network. CUPS as it impacts Wireless Wireline Convergence is documented in TR-470 Section 5.2 [12] whilst TS 23.501 [14] details the architectural elements. From the perspective of a 5G-RG, CUPS has the following impacts:

• Control plane communications move from transient (DHCP and PPP LCP ) to persistent (NAS). As a result, the operator can now modify a customer session at any time rather than at the point of authorization.
• Traffic for control and user planes uses separate sessions over a common PHY.
• DHCP and DHCPv6 technically move from the control to the user plane (UPF responsibility). However, both protocols can and need to be used to deliver configuration via their options.

XXV.2.3 Multiple Sessions - 3, 4 and 5G

One of the more significant features of using NAS signalling is the support of multiple user plane sessions. Each session can be considered a virtual circuit between the RG and the operator’s network core. The terminology varies with each generation starting with PDP context for 3G through to PDU session for 5G. Each session instance can be assigned IP addresses, QoS rules and even guaranteed bit rates. This leads to applications requiring:

• Separate IP sessions.
• Preferential data paths within the operator’s network.
• Traffic separation for security.
• Guaranteed bit rates for a given application.

TR-470 Section 6.2 [12] provides examples of multiple PDU scenarios for a 5G-RG.

XXV.2.4 Quality of Service (QoS) - 3G, 4G and 5G

QoS as implemented in a 3GPP based system is heavily influenced by the needs of the radio bearer. In particular the familiar packet marking techniques such as DSCP and PCP are ineffective over radio. Instead a focus on packet prioritization is the foundation of 3GPP QoS.

XXV.2.4.1 3G QoS

Capabilities: * Guaranteed and non-guaranteed bit rates * Packets in a PDP context are mapped to a single traffic class (e.g., conversational, streaming, interactive, and background) * Each PDP Context has its own bearer

XXV.2.4.2 4G QoS

Capabilities: * Guaranteed and non-guaranteed bit rates * Increased granularity with QCI offering predefined QoS capabilities such as priority, packet delay and error rate. In addition to the standard 3GPP defined values, operators can define their own QCI capabilities. * Allocation and Retention Policy (ARP). * Traffic for each QCI and ARP combination within a PDN will be mapped to its own bearer.

XXV.2.4.3 5G QoS

Unlike the previous generations, 5G QoS marking is merely a label called a QoS Flow Indicator (QFI). End-to-end QoS as documented in TR-470 Section 5.1 [12] is a key outcome of policy. As part of PDU establishment, a set of QoS rules is supplied specific to that PDU. Consequently, the access network specifies not only the supported QFI labels but also the properties of the QoS profile. A QoS profile consists of the following properties:

• 5G QoS Identifier (5QI). Unlike a QFI, 5QI does have a defined set of properties such as priority and whether its bit rate is guaranteed.
• Allocation and Retention Policy (ARP).
• For Guaranteed Bit Rate (GBR) profiles the guaranteed and maximum upload and download bit rates.
• GBR profiles may also specify a maximum packet loss.

XXV.2.5 Multiple Access Networks -5G

Whilst FN-RGs are perfectly capable of supporting multiple access networks, each access network operates independently with separate IP addresses and an inability to seamlessly switch traffic between them. A 5G-RG can modify a PDU and switch traffic to another supported access network and maintain all the PDU properties including IP addresses. An operator can optimize its network usage by sending policy rules to a 5G-RG, indicating the preferred access and data networks. TR-470 Section 4.4 [12] provides a more in-depth description of hybrid access.

XXV.2.6 Network Slicing - 5G

An operator may choose to partition their network infrastructure for the purposes of resiliency or merely to optimize for a particular function such as IoT. Each instance of the partitioned network is called a network slice. Operators will provide slice information as part of URSP policy rules. Every PDU at the time of establishment must specify a network slice. Slicing is further documented in TS 23.501 Clause 5.15 [14].

XXV.3 Data Model elements

XXV.3.1 Data Model

XXV.3.1.1 Device.SessionManagement - 3G, 4G and 5G

The logical connection between an RG and a data network using 3GPP technologies (FN-RG cellular and 5G-RG ALL) are considered data sessions. The Device.SessionManagement subtree describes each sessions properties together with the QoS rules specific to that access technology.

XXV.3.1.2 Device.WWC - 5G

The relationship between a 5G-RG and the available access networks is represented by the Device.WWC object tree. All objects are read only and are intended for service assurance purposes.

XXV.3.1.3 Device.FWE - 5G

5G Wireless Wireline Convergence User Plane Encapsulation [66] is used to separate each PDU session when multiplexed over a PHY. A Device.FWE.Link object is inserted into the interface stack, providing PDU session id as well as 5G QoS markings (QFI, RQI). This is also the level at which fixed QoS rules are applied in order to traverse access networks that do not natively support 5G QoS (QFI) markings. An instance of this object will be created by a 5G-RG whenever a PDU is established.

XXV.3.2 Interface Stack - 3G, 4G and 5G

The ability to provide multiple user sessions using 3GPP NAS signalling makes some subtle changes to how the interface stack is viewed. The most significant are the multiple PDP/PDN/PDU sessions shown in parallel but linked to a common access technology. This is not to be confused with features such as bonding as the traffic for each session is segregated on the radio interface.

All 3GPP based interface stacks require an OSI layer to segregate multiplexed traffic. The OSI layer model (see Figure 10) represents all 3GPP technologies (Cellular and 5G fixed) at ‘L2---’ and the previous ‘L2--’ pushed down to ‘L2---’.

The scenarios below show 5G PDU examples. However, the cellular interface mapping is equally applicable for 3G PDP and 4G PDN sessions.

XXV.3.2.1 Scenario #1 - Fixed access network only

This example shows two PDU sessions using a VDSL access network. As this is a fixed service, the 5WE protocol is used to multiplex the PDU traffic over the VDSL service. NAS traffic is separate from the PDU traffic and is carried as PPPoE over the VDSL service. All LAN traffic remains unchanged on a 5G-RG.

XXV.3.2.2 Scenario #2 - Cellular access network only

This example shows two PDU sessions using a cellular access network. In this case the 5G-RG does not to need to multiplex the PDU traffic as the cellular module handles that internally. NAS traffic does not appear in this diagram as the requests are made directly to the cellular module. Depending on the cellular module, each PDU may need to be carried over a VLAN (this has been omitted for the moment). All LAN traffic remains unchanged on a 5G-RG.

XXV.3.2.3 Scenario #3 - Hybrid (Fixed and Cellular) access

This example shows two PDU sessions using both VDSL and cellular access networks. Either access network is capable for carrying either PDU or both. A PDU in this situation can only be carried on a single access network at a time. Fixed traffic is multiplexed using 5WE (even if only one PDU is present) whilst PDU traffic to the cellular network is multiplexed by the cellular module. NAS traffic using the PPP interface is for the fixed component only as cellular requests are made directly to the cellular module. Depending on the cellular module, each PDU may need to be carried over a VLAN (this has been omitted for the moment). All LAN traffic remains unchanged on a 5G-RG.

XXV.3.3 Examples

There are a multitude of combinations of 3GPP generations and access technologies. The following scenarios will be explored: * 3G PDP - Cellular - General purpose internet traffic. * 4G PDN - Cellular - General purpose internet traffic, IMS VoIP * 5G PDU - Cellular - General purpose internet traffic, IMS VoIP, traffic marking for VoWiFi * 5G PDU - Fixed - General purpose internet traffic * 5G PDU - WWC - General purpose internet traffic, IMS VoIP, traffic marking for VoWiFi

XXV.3.3.1 Scenario #1 - 3G PDP - Cellular - General purpose internet traffic