The P-LTE-450 is a 450MHz Category-4 LTE PIM, which addresses LTE use cases primarily targeting utility, public safety, and critical infrastructure maintained by public organizations in Europe and other world regions. The module supports only Band 31 and 72 for LTE 450MHz networks.

Note	Throughout the user documentation, you will see the module referred to as P-LTE-450, which is the Cisco product name. The module is designed and manufactured by Intelliport, which refers to it as the IPS-701. Both names will be present in documentation.

Unlike regular LTE modules, there are some differences with regards to the P-LTE-450MHz on IOS-XE platform. Some of the key differences are:

• IP pass through will be on Gigabit Ethernet interfaces rather than cellular interface

• Troubleshooting commands are from web interface of third-party hardware

See the Cellular Pluggable Interface Module Configuration Guide for complete details.

For additional information, see the LTE 450MHz Alliance.

The Sydney Coordinated Adaptive Traffic System (SCATS), is an intelligent transportation system that manages the dynamic (on-line, real-time) timing of signal phases at traffic signals, meaning that it tries to find the best phasing (i.e. cycle times, phase splits and offsets) for a traffic situation (for individual intersections as well as for the whole network).

High-Level Data Link Control (HDLC) is a group of data link (Layer 2) protocols used to transmit synchronous data packets between point-to-point nodes. Data is organized into addressable frames.

This feature is being developed as an IOx app which integrates with the existing virtualization layers available in IOS XE based IoT routers. The intended application is to have a SCATS controller connected to the router via serial cable.

The following figure is an example of a typical SCATS traffic control network application:

In the above figure, an IR1101 plays the role of the DSL Router to which the Traffic Signal Controller (TSC) is connected via a serial interface. Upon connection to the TSC, the router obtains a Site ID from the controller, which it will then forward to the SCATs Authentication Server. The authentication servers will be provided to the IOx app through a JSON file including IP and port and there can be up to three authentication servers that the IOx app can cycle through.

Once the Authentication Server has received the Site ID, it will reply to the router with the corresponding SCATs regional computer IP and port that matches that Site ID. All further communication is then done transparently from TSC to Regional Computer.

The router will use two modes to communicate with the TSC (HDLC and non-HDLC). There are four available serial configurations, and the user can select which configurations will be used by enabling or disabling them through a second JSON file provided to the app.

Since this is an IOx app, the feature can be disabled by stopping, deactivating, or uninstalling the app. The application will mainly be deployed using Local Manager. App size is about 50 MB, CPU is 400 units and memory is 128 MB.

This feature allows accelerometer and gyro sensor data from IRM-GNSS (GPS DR) module to be streamed to the IOX via a TTY in IR1800. Prior to this release, the IRM-GNSS module pushed the sensor data to the host in NMEA via port /dev/ttyS2. Previous IOS XE releases already parsed and cached the data.

The feature will forward the sensor data to IOX via the TTY whenever the data is received from the NMEA. Currently, there is no control on the frequency the data is sent from the module, which totally relies on the module itself.

There are no new commands for this feature. It is enabled by default once dead reckoning is enabled. Existing CLIs can be used to view the sensor data, for example:

Router# show platform hardware gps dead-reckoning

DR Vehicle interface mode: OBDDII
GPS/DR Vendor Info: TELIT
GPS/DR module FW Version: V33-1.0.5-CLDR-4.7.10-N115R115-003291-3
…
Raw Accel Data in X:  -542
Raw Accel Data in Y:  538
Raw Accel Data in Z:  16964
Raw Gyro Data in X:  153
Raw Gyro Data in Y:  -80
Raw Gyro Data in Z:  99

The existing debug platform hardware gps dead-reckoning command has been enhanced to provide additional debug messages for better serviceability. The debug messages will cover the following:

• How frequent the sensor data are pushed from the module to IOS, it must at least once per second.

• The latest sensor data received from the module.

This feature provides 5G Standalone mode (SA) support on the P-5GS6-GL pluggable module. The 5G SA mode support will enable 5G cellular configuration display using Cisco IOS-XE CLI commands.

This feature provides a mechanism in the CLI to select a set of bands for SA mode, as opposed to a single band in previous software releases. The following IOS-XE CLIs have been modified for 5G SA mode support:

• show cellular radio

• show cellular radio details (without carrier aggregation)

• show cellular network

There is also a band selection CLI to select cellular bands.

Router#show cellular 0/2/0 radio
Radio power mode = Online
5G Rx Channel Number = 632544
5G Tx Channel Number = 632544
5G-SA Band = 78
Bandwidth = 20 MHz
Current 5G RSSI = -60 dBm
Current 5G RSRP = -71 dBm
Current 5G RSRQ = -11 dB
Current 5G SNR = 34.5 dB
Physical Cell Id = 500
Radio Access Technology(RAT) Preference = AUTO
Radio Access Technology(RAT) Selected = 5GNR-SA

Router#show cellular 0/4/0 radio detail
 Modem Radio is Online
 Main 0 Antenna details:
 RSSI = -38 dBm
 RSRP = -48 dBm
 Diversity 0 Antenna details:
 RSSI = -47 dBm
 RSRP = -58 dBm

Router#show cellular 0/4/0 network
Current System Time = Sun Jan 6 0:4:36 1980
Current Service Status = Normal
Current Service = Packet switched
Current Roaming Status = Home
Network Selection Mode = Automatic
Network = Test PLMN 1-1
Mobile Country Code (MCC) = 1
Mobile Network Code (MNC) = 1
Packet switch domain(PS) state = Attached
Tracking Area Code (TAC) = 1
Cell ID = 1024
Negotiated network MTU = 1500

Band Selection Command Example

The lte modem band-select CLI can be used to enable bands that the user wishes to use and subscribe to. By default SA bands are not available.

Important

If you wish to use SA bands, the lte modem band-select command MUST be used as part of the configuration.

The following is an example of the command:

conf t
controller cellular 0/2/0
lte modem band-select indices umts3g all lte4g all nr5g-NSA all nr5g-SA 78 slot 0
exit

The following shows an example of using nr5g-sa band 48:

lte modem band-select indices umts3g "23" lte4g "7" nr5g-nsa "12" nr5g-sa "48" slot 0

Note	In the above example, umts3g band 23, lte4g band 7, and nr5g-nsa band 12 are not available in the area, which means the modem will only attach to nr5g-nsa band 48.

The following shows an example of using nr5g-sa band 78:

lte modem band-select indices umts3g "23" lte4g "7" nr5g-nsa "78" nr5g-sa "none" slot 0

Note	In the above example, umts3g band 23 and lte4g band 7 are not available in the area, and nr5g-sa bands are turned off which means the modem will only attach to nr5g-nsa band 78.

Unified Thread Defense (UTD) is Cisco's premier network security solution which provides a comprehensive suite of security features, such as firewall capabilities, monitoring, alerts, and IDS/IPS, Web-Filtering, Multi-tenancy and Anti-Malware Protection.

Beginning with the Cisco IOS XE 17.12.1a release, Precision Time Protocol (PTP) can operate over Parallel Redundancy Protocol (PRP) on the Cisco Catalyst IR8340 Rugged Series Router. The support for PTP over PRP is the same as that on the Cisco Catalyst IE9300 Rugged Series Switches. Full documentation is available in the Redundancy Protocol Configuration Guide, Cisco Catalyst IE9300 Rugged Series Switches.

The following details pertain to the IR8340:

• Supported PTP clock and profiles:

  • Boundary Clock (BC) – Default Profile, Power profile

  • Transparent Clock (TC) – Peer-to-peer transparent (P2P)

• The PTP over PRP will be supported for only one PTP clock domain at any given time

• There are 2 PRP channels:

  • Channel 1: Ports Gig0/1/4 and Gig0/1/5

  • Channel 2: Ports Gig0/1/6 and Gig0/1/7

• PTP over PRP is supported with GNSS/Telecom enabled on the system. The Redbox shall be in PRTC/Wan to LAN conversion mode, with ports being in Master state only.

• The other clock domains can have non PRP interfaces configured with PTP over PRP enabled on one domain.

MACsec is an IEEE 802.1AE standards based Layer 2 hop-by-hop encryption that provides data confidentiality and integrity for media access independent protocols.

MACsec, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the required encryption keys.

The 802.1AE encryption with MACsec Key Agreement (MKA) is supported on downlink ports for encryption between the routers or switches and host devices.

MACsec encrypts the entire data except for the Source and Destination MAC addresses of an Ethernet packet. To provide MACsec services over the WAN, service providers offer Layer 2 transparent services such as E-Line or E-LAN using various transport layer protocols such as Ethernet over Multiprotocol Label Switching (EoMPLS) and L2TPv3.

The packet body in an EAP-over-LAN (EAPOL) Protocol Data Unit (PDU) is referred to as a MACsec Key Agreement PDU (MKPDU). When no MKPDU is received from a participants after 3 hearbeats (each hearbeat is of 2 seconds), peers are deleted from the live peer list For example, if a client disconnects, the participant on the switch continues to operate MKA until 3 heartbeats have elapsed after the last MKPDU is received from the client.

The MKA feature support provides tunneling information such as VLAN tag (802.1Q tag) in the clear so that the service provider can provide service multiplexing such that multiple point to point or multipoint services can co-exist on a single physical interface and differentiated based on the now visible VLAN ID.

In addition to service multiplexing, VLAN tag in the clear also enables service providers to provide quality of service (QoS) to the encrypted Ethernet packet across the SP network based on the 802.1P (CoS) field that is now visible as part of the 802.1Q tag.

Previous releases of IOS XE offered support for IPv4 unicast traffic over an IPv4 DLEP session. IOS XE 17.12.1a provides support for IPv6 unicast over an IPv4 DLEP session.

This section provides a subset of the overall DLEP information that is found in the IP Routing Configuration Guide, Cisco IOS XE 17.x.

The Cisco IOS XE 17.11.1 release introduced a new throughput level called "uncapped". This release extends the new throughput level to all of the Cisco IoT routing platforms. The following is a recap of the uncapped license implementation:

Licensing Throughput Levels

The throughput level determines the bandwidth limit which is applied to encrypted traffic. There is no limit applied to the non-encrypted (clear) traffic going through a device.

Important

To comply with global export regulations, if more than 250Mbs of encrypted traffic is required, then an “uncapped” – platform dependent – selection must be done on CCW, as well as an HSEC license.

This limit is imposed bidirectionally. This means that if the throughput limit is set to 250Mbps then up to 250Mbps of encrypted traffic can flow through the device in either direction. For example, the device can both receive and transmit up to 250Mbps of encrypted traffic. There is no limit applied on unencrypted traffic.

When the throughput level on the device is set to "uncapped" there are no limits imposed on both encrypted and unencrypted traffic flowing through it.

Note	To avoid confusion on throughput limits and IOS XE software releases, please note the following:

Cisco IOS XE release 17.11.1a and earlier running on the ESR6300, IR1800, and IR8140 platforms support boost, uncapped, and unlimited licenses. These are configured using the platform hardware throughput level 2G CLI.

Future Cisco IOS XE release 17.12.1a and later running on the ESR6300, IR1800, and IR8140 support the same licenses, but will be configured using the platform hardware throughput level uncapped CLI.

With Cisco IOS XE release 17.12.1a and later, the platform hardware throughput level 2G and the platform hardware throughput level uncapped CLIs will both provide the same throughput as the uncapped license.

The following table shows the throughput limits (also referred to as Tier license) supported on IoT devices.

Platform	25 Mbps bidirectional (Tier 0)	50 Mbps bidirectional	Up to 200 Mbps bidirectional (Tier 1)	250 Mbps bidirectional	2 Gbps	Uncapped (Tier 2)
ESR 6300	N/A	Yes	N/A	Yes	Yes	Supported starting with 17.12.1a
ESR-6300-LIC-K9	N/A	Yes	N/A	N/A	N/A	Yes
IR1101	N/A	N/A	N/A	Yes	N/A	Supported starting with 17.10.1.
IR1800	N/A	Yes	N/A	Yes	Yes	Supported starting with 17.12.1a
IR8100	N/A	Yes	Yes	Yes	Yes	Supported starting with 17.12.1a
IR8300	Yes	N/A	Yes	N/A	N/A	No