This section describes common external services such DNS, DHCP, NTP, and PTP required for the Telco Cloud Platform RAN solution deployment.

Various external services are required for the deployment of the Telco Cloud Platform RAN components and Tanzu Kubernetes clusters. If you deploy the Telco Cloud Platform RAN solution in a greenfield environment, you must first deploy your Regional Data Center site and then onboard the Cell Sites to the Telco Cloud Platform RAN solution.

The following table lists the required external services and dependencies for Regional Data Center site and Cell Site locations:

Service

Purpose

Domain Name Services (DNS)

Provides name resolution for various components of the Telco Cloud Platform RAN solution.

Dynamic Host Configuration Protocol (DHCP)

Provides automated IP address allocation for Tanzu Kubernetes clusters at Regional Data Center and Cell Site locations.

Note: Ensure that the DHCP service is available local to each site.

Network Time Protocol (NTP)

Performs time synchronization between various Telco Core management components at Central Data Center or Regional Data Center.

Precision Time Protocol (PTP)

Distributes accurate time and frequency over telecom mobile networks and ESXi host at Cell Site locations.

DNS

When you deploy the Telco Cloud Platform RAN solution, provide the DNS domain information for configuring various components of the solution. DNS resolution must be available for all the components in the solution, including servers, Virtual Machines (VMs), and virtual IPs. Before you deploy the Telco Cloud Platform RAN management components or create any workload domains, ensure that both forward and reverse DNS resolutions are functional for each component.

DHCP

Telco Cloud Platform RAN uses Dynamic Host Configuration Protocol (DHCP) to automatically configure Tanzu Kubernetes Cluster with an IPv4 address at Regional Data Center and the Cell Site location. Each RDC and Cell Site must have a dedicated DHCP service locally, and the DHCP scope must be defined and made available for this purpose. The defined scope must be able to accommodate all the initial and future Kubernetes workloads used in the Telco Cloud Platform RAN solution.

The following figure shows the deployment architecture of the DHCP service for a Regional Data Center and Cell Site location:

Figure 1. DHCP Design for Regional Data Center and Cell Site Locations
DHCP Design for Regional Data Center and Cell Site Locations
Note:

While deploying the Tanzu Kubernetes Control Plane, dedicate a static IP for the Kubernetes API endpoint.

NTP

All the management components of Telco Cloud Platform RAN must be synchronized against a common time by using the Network Time Protocol (NTP). The Telco Cloud Platform RAN components such as vCenter Server Single Sign-On (SSO) are sensitive to a time drift between distributed components. The synchronized time between various components also assists troubleshooting efforts.

The following guidelines apply for the NTP sources:

  • The IP addresses of NTP sources can be provided during the initial deployment of Telco Cloud platform RAN.

  • The NTP sources must be reachable by all the components in the Telco Cloud Platform RAN solution.

  • Time skew between NTP sources must be less than 5 minutes.

PTP

Precision Time Protocol (PTP) delivers time synchronization in various Telco applications and environments. It is defined in the IEEE 1588-2008 standard. PTP helps issuing accurate time and frequency over telecommunication mobile networks. Precise timekeeping is a key attribute for telco applications. It allows these applications to accurately construct the precise sequence of events that occurred or occur in real time. So, each ESXi node in the Telco Cloud Platform RAN solution must be time-synchronized.

Note:

The precision of a clock describes how consistent its time and frequency are relative to a reference time source, when measured repeatedly. The distinction between precision and accuracy is subtle but important.

PTP profiles: PTP allows various profiles to be defined to amend PTP for use in different scenarios. A profile is a set of specific PTP configuration options that are selected to meet the requirements of telco RAN applications.

PTP traffic: If the network carrying PTP comprises a non-PTP-aware switch in the pathway between the Grandmaster and Follower clocks, the switch handles PTP as any other data traffic, affecting the PTP accuracy. In this case, use a proper Quality-of-Service (QoS) configuration for network delivery to prioritize PTP traffic over all other traffic.

PTP grandmaster clocks: When networks are distributed geographically across different locations with Central Data Center, Regional Data Center, and Cell Site and they are connected over Wide Area Networks (WAN), varying latency across WAN link can compromise PTP accuracy. In that case, use different PTP Grandmaster clocks in each site and do not extend PTP across these sites.

The following guidelines apply for the PTP sources: ESXi host must have a third physical NIC dedicated for PTP synchronization.

  • The PTP sources such as Telco Grandmaster Clock (T-GM) must be reachable by all the components in the Telco Cloud Platform RAN solution.

  • Use G.8275.1 PTP profile for accurate time synchronization for RAN applications. ITU–T G.8275.1 defines PTP profile for network scenarios with full-timing support, which means all the intermediate switches support Boundary Clock functionality (BC).

  • For the Cell Site locations, each host must have a minimum of two dedicated physical NICs. These NICs are used for ESXi management and workloads. PTP may run on an SR-IOV VF or an additional dedicated physical NIC.

The following figure shows the physical NIC placement for PTP on an ESXi host:

Figure 2. PTP Design for ESXi Host at Cell Site
PTP Design for ESXi host at Cell Site
Note:

In case of a dual-socket host with NUMA placement, use four physical NICs. Each socket must be mapped to two physical NICs.