Join Kubernetes Worker Node to an existing Cluster:

Before you begin 

1. Two working node culesters are needed.
   
2. You need to have a working Kubernetes cluster – configured and working control plane node
3. Docker, Kubernetes tools(kubeadm and kubelet) and CNI plugins(CALICO, flannel) should installed in your Worker node
4. If using Firewall such as firewalld, ports 10250, 30000-32767 and ports required by your Pod network add-on should be opened in the firewall.
5. SSH access to the machine to be added
6. Configured kubectl for checking if the node is available in your cluster
7. These standard requirements are covered in detail in our Kubernetes cluster installations. 

Generate new token to join work node :
Use command below to generate the join command for work node.
 
kubeadm token create --print-join-command
 
output:

[root@SERVER-worker ~]# kubeadm token create --print-join-command
kubeadm join 192.19.74.111:6443 --token syjqnu.0q6piceqoxxfxiui --discovery-token-ca-cert-hash sha256:fa9bb688d19eecbda4db75bff49416282918d126c9bd94100066f06d4b3a780e
 

 Yellow highlighted is a command to join this node to the master node, copy this command, and execute this on master node server.

Now go to the master node server, and execute the join command.

Output will be:
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.17" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
 
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
 
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

After that Wait for some time to get Nodes “Ready”. below is the command to check  the status of worker node. all the nodes attached with master node will start showing here.

watch kubectl get nodes

5G(NR): Xn Based Handover

5G(NR): Xn Based Handover

 

Introduction:

The basic handover procedures is same in any networks, i.e. UE reports measurement report with neighbor cell PCI and signal strength to source cell, source cell take the decision to start handover procedure to best target cell and Target Cell completes the Handover procedure.

 

Impotent Pointers for Xn Handover:

1. Signal strength of both source gNB and target gNB should be reachable to UE during the HO. 
   
2. Xn Handover is similar X2 Handover in 4G LTE
   
3. XnAP interface must be established between source and Target gNB.
4. This type of Handover is only applicable for intra-AMF mobility, i.e. Xn handover cannot be used if Source and Target gNB is connected to different AMF
5. Xn Handover can be Intra Frequency HO and Inter Frequency HO
6. Source and Target gNB can be connected with two different UPFs
7. Tracking Area code should be same. Re-Registration is required after Successful Handover if the Source gNB and Target gNB belong to different Tracking Area (TAC)
8. Xn Handover is Faster as Compare to N2/NGAP Handover due to short signalling path and 5G Core involved in only for switch the PDU session path

High level setup diagram:

      where both the gNB is served by same AMF and UPF. and for XnHO, XnAP interface is active between source gNB and target gNB.

Signaling Exchange b/w Source gNB and target gNB.