User Guide

1 Operating a Video Stream Cloud Phone Instance

1.1 Starting a Video Stream Cloud Phone Instance

You can set parameters in the cfct_config file to start video stream cloud phone instances with different resolution and frame rates, and set the initial video encoding parameters in the default.prop file. If you use an APK to access the video stream cloud phone, you can configure the snapshot resolution in the APK settings.

1. (Optional) To start video stream cloud phone instances with custom frame rates, modify the frame rate property in the cfct_config file. The default frame rate is 30 fps. 60 fps is also supported when the resolution is 720p or 1080p.

   BUILD_FPS=30

2. (Optional) To start video stream cloud phone instances with the C2 decoder enabled (applicable to configuration scheme 1), configure ENABLE_AMD_C2_DECODE=1 in the cfct_config file. 0 (default) and any other values indicate disabled. The C2 decoder needs to be enabled or disabled during the initial container startup; dynamic switching is not supported. Built-in cloud phone applications will automatically select the appropriate decoder based on their specific requirements.

   ENABLE_AMD_C2_DECODE=0

3. To start video stream cloud phone instances with custom initial encoding parameters, snapshot resolutions, and audio and video output formats, perform the following operations:

   1. Decompress DemoVideoEngine.tar.gz to obtain the vendor folder and copy the default.prop file in the folder to the current directory.

      cd /home/kbox_video/
      tar -xvf DemoVideoEngine.tar.gz vendor
      cp vendor/default.prop .

   2. Set initial encoding parameters by configuring property fields started with vmi.video.encode in default.prop. For details about the property fields, see 3.2.1-Configuration Items in the Startup Script.

   3. Set the snapshot resolution by configuring property fields started with vmi.video.frame in default.prop. For details about the property fields, see 3.2.1-Configuration Items in the Startup Script. After changing the resolution, you are advised to change the screen pixel density in the cfct_config file as well to achieve the optimal display effect. Table 1 lists the recommended configurations.

      Table 1 Recommended configurations for different resolutions

      Screen Width (BUILD_WIDTH)	Screen Density (BUILD_DENSITY)
      360	120
      480	160
      720	320
      1080	480
      1440	640
      2160	960

      After you change the video output resolution (to a resolution different from the configuration at the last startup), the rendering resolution of the AOSP system and apps is changed. In this case, a compatibility issue or rendering problem may occur in some apps. Generally, this problem can be solved by restarting apps. It is recommended that you return to the home screen and clear background apps before changing the resolution. Modifications in the default.prop file do not take effect immediately after you start the container. You need to manually restart the container to apply the modifications.

   4. Set the audio and video output formats.

      If you access a video stream cloud phone instance using an APK, configure property fields in default.prop to set video and audio output formats. For details, see 3.2.1-Configuration Items in the Startup Script.

4. Start a video stream cloud phone.

   cd /home/kbox_video/
   ./cfct_video start ${index1} 

   ${index1} in the preceding command indicates the ID of the instance to be started. Start a video stream cloud phone whose index is 1.

   ./cfct_video start 1

   During the container startup, errors such as "writing syncT "procError"", "exec /system/bin/chmod: no such file", and "/system/bin/getprop:no such file" may occur. These errors do not affect the functionality and can be ignored. To start multiple cloud phone instances, run the following command:

   ./cfct_video start ${start_index} ${end_index}

   To use NFS for mounting, change start to nstart. Example:

   ./cfct_video nstart ${start_index} ${end_index}

5. List video stream cloud phones running on the Docker container runtime.

   docker ps -a

   Example command output:

   

   Make sure that the started container can be found and is in normal state.

6. Check whether the video stream cloud phone has been successfully started on the Docker container runtime. ${index} indicates the instance ID. For example, in the last column in the command output of 5, ${index} of android_35 is 35.

   docker exec -it android_${index} sh 

   getprop sys.boot_completed

   If the value of sys.boot_completed in the output is 1, the startup is successful.

   

1.2 Querying Component Version Information

This section provides the following two methods to obtain the version of the video stream engine component.

Method 1: using the obtained software package

1. Refer to Video Stream Engine Installation Guide to obtain BoostKit-boostcph-videoengine_*_15.zip and decompress it to obtain the version file.

2. Check the version of the video stream engine component.

   unzip BoostKit-boostcph-videoengine_*_15.zip
   tar -xvf  VideoEngine.tar.gz vendor/etc/videoengine_version.txt
   cat vendor/etc/videoengine_version.txt

   The command output is the version information of the video stream engine component. An example is as follows:

   Product Name: Kunpeng BoostKit
   Product Version: 26.0.RC1
   Component Name: BoostKit-boostcph-videoengine
   Component Version: 8.0.RC1
   Component AppendInfo: 15.0.0_r17

Method 2: calling an external API of the video stream engine

Call the GetVersion API to obtain the version information. For details, refer to "External APIs > Function APIs > GetVersion" in Video Stream Engine Developer Guide. The command output example is the same as that in method 1.

1.3 Accessing a Video Stream Cloud Phone

1.3.1 Using an APK

If the video stream cloud phone is started in the default mode, you can access the cloud phone using an APK.

1. Decompress CloudPhoneApk.tar.gz.

2. Install CloudPhone.apk on an Android phone.

3. (Optional) Tap the gear icon in the upper right corner to access the settings screen.

4. Return to the home page, enter the server IP address and port in top-down order, and tap Connect to access the video stream cloud phone.

   The default port is 8000 + ${index}.

   • A port must be configured for each video stream cloud phone instance. This can be set in the cfct_video script during deployment. The port number ranges from 1024 to 65535 and cannot be an occupied port to avoid port contention and video stream cloud phone access failure.
   • The video stream engine client is 64-bit and must run on 64-bit Android mobile phones running HarmonyOS or Android 7 or later.
   • Ensure that the network connection between the mobile phone and the server is normal.

1.4 (Optional) Dynamically Modifying Cloud Phone Parameters

You can use CloudPhone.apk to dynamically modify the video and audio encoding parameters when the cloud phone is running.

1. After connecting to the cloud phone, tap the gear icon on the screen.

2. Set video encoding parameters.

   1. Tap the video icon.

   2. Set the video encoding parameters.

      For details about the value range of each parameter, see the properties starting with vmi.video.encode in 3.2.1-Configuration Items in the Startup Script. The rendering resolution can be 360p, 720p, or 1080p.

   3. After the setting is complete, tap Send to send the parameter values to the server. If the values are valid, they take effect immediately.

      You can run the setprop command in the container after starting the cloud phone to change property settings. For details about the property fields, see 3.2.1-Configuration Items in the Startup Script.

3. Set audio encoding parameters.

   1. Tap the audio icon.

   2. Set the audio encoding parameters.

      For details about the value range of each parameter, see the properties starting with vmi.audio.encode in 3.2.1-Configuration Items in the Startup Script.

   3. After the setting is complete, tap Send to send the parameter values to the server. If the values are valid, they take effect immediately.

1.5 Restarting a Video Stream Cloud Phone Instance

Run the cfct_video script to restart a video stream cloud phone instance.

Restart a video stream cloud phone whose index is ${index1}.

./cfct_video restart ${index1}

1.6 Deleting a Video Stream Cloud Phone Instance

Run the cfct_video script to delete a video stream cloud phone instance.

Delete a video stream cloud phone whose index is ${index1}.

./cfct_video delete ${index1}

./cfct_video ndelete ${index1}

2 Operating a Video Stream Cloud Phone Instance in the Kubernetes Cluster

2.1 Starting the DaoCloud Device Plugin

Start the DaoCloud device plugin on the master node. Before starting the plugin, obtain the TAR package of the video stream engine server for obtaining the audio and video data of the Kbox container.

Obtain DemoVideoEngine.tar.gz based on Video Stream Engine Installation Guide and upload it to the /home/k8s directory on the server.

1. Decompress DemoVideoEngine.tar.gz.

   cd /home/k8s/
   tar -xvf DemoVideoEngine.tar.gz

2. Create a label (va-device=va-sg100) on the specified Kubernetes node.

   kubectl label nodes $NODENAME va-device=va-sg100

   $NODENAME indicates the name of a worker node.

3. Create a namespace va-plugin.

   kubectl create ns va-plugin

4. Create a ConfigMap object va-plugin and add the content of the config.yaml file to the ConfigMap.

   cd /home/k8s/k8s/script
   kubectl create cm -n va-plugin va-plugin-configs --from-file=config=config.yaml

5. Change the name of the DaoCloud device plugin image.

   vi va-device-plugin.yaml

   Change the value of the following field to the actual value:

   spec.spec.containers.image: Enter the name of the DaoCloud device plugin image imported to the worker node.

6. Start the DaoCloud device plugin.

   cd /home/k8s/k8s/script
   kubectl create -f va-device-plugin.yaml

   You can run the kubectl delete -f va-device-plugin.yaml command to delete the DaoCloud device plugin.

7. After the startup is complete, check whether the DaoCloud device plugin can run properly.

   kubectl get pods -A

   It is expected that the STATUS column of Pods whose names start with va-device-plugin-daemonset is Running.

2.2 Starting the Device Plugin

Start the device plugin on the master node.

1. Start the device plugin.

   cd /home/k8s/k8s/script
   ./start_devices.sh

   After the ./start_devices.sh command is executed for the first time, some errors are reported because the script deletes the daemonSet of the device plugin. You can run the ./delete_devices.sh command to delete the device plugin.

2. After the startup is complete, check whether the device plugin can run properly.

   kubectl get pods -A

   It is expected that the STATUS column of Pods whose names start with k8s-host-device is Running.

2.3 Running the Hook Script

Run the hook script on all worker nodes.

1. Obtain DemoVideoEngine.tar.gz based on Video Stream Engine Installation Guide and upload it to the /home/k8s directory on the server.

2. Copy the oci-device-hook.sh script in the /home/k8s/k8s/script directory to the /usr/local/sbin/ directory.

   cd /home/k8s/k8s/script
   cp oci-device-hook.sh /usr/local/sbin/

3. Modify the containerd configuration by changing the container runtime added in Deploying the DaoCloud Device Plugin Image to /usr/local/sbin/oci-device-hook.sh.

   sed -i 's|BinaryName = "/usr/bin/va-container-runtime"|BinaryName ="/usr/local/sbin/oci-device-hook.sh"|g' /etc/containerd/config.toml

4. Restart containerd.

   systemctl restart containerd

2.4 Running the NRI Plugin

Run the NRI plugin on all worker nodes.

1. Obtain DemoVideoEngine.tar.gz based on Video Stream Engine Installation Guide and upload it to the /home/k8s directory on the server.

2. Go to the /home/k8s/k8s/scripts/nri-quota-plugin directory and build the plugin.

   go build -o quota-plugin main.go

3. Configure containerd and restart it to enable NRI.

   Set disable to false in the /etc/containerd/config.toml file.

   [plugins."io.containerd.nri.v1.nri"]
   disable = false
   plugin_config_path = "/etc/nri"
   plugin_socket_path = "/var/run/nri"

   Restart containerd.

   systemctl restart containerd

4. Deploy the plugin.

   mkdir -p /var/log/nri /var/run/nri
   cp quota-plugin /opt/nri-quota-plugin/
   chmod +x /opt/nri-quota-plugin/quota-plugin

5. Start the NRI plugin.

   cp quota-plugin.service /etc/systemd/system/quota-plugin.service
   systemctl daemon-reload
   systemctl enable quota-plugin
   systemctl start quota-plugin

2.5 Starting a Kubernetes Video Stream Cloud Phone Instance

Perform the following operations on worker nodes.

1. Modify the k8s-video.yaml file.

   cd /home/k8s/k8s/script
   vi k8s-video.yaml

   Change the following fields to the actual values:

   • spec.containers.image: video stream image. Enter the name of the video stream image imported to the worker node.
   • spec.containers.resources.limits.cpu and spec.containers.resources.requests.cpu: number of cores to be bound to containers. The two fields need to be modified together.
   • spec.containers.resources.limits.memory and spec.containers.resources.requests.memory: container memory. The two fields need to be modified together.

2. Start a Kubernetes video stream cloud phone.

   Note: If the created data volume is in f2fs format, the f2fs switch must be configured to 1. If the created data volume is in ext4 format, the f2fs switch must be configured to 0.

   ./k8s-video.sh start ${index1} ${index2} ${index3} ${index4} 

   To use NFS for mounting, change start to nstart. Example:

   ./k8s-video.sh nstart ${index1} ${index2} ${index3} ${index4} 

   ${index1} and ${index2} are Pod indexes. ${index3} indicates whether to enable the f2fs format for files in the container (1 enables it, while 0 (default) disables it). ${index4} indicates the size allocated to the /system partition inside the container, in MB. Entering a value greater than 0 enables it, while entering 0 or leaving it blank disables it. This configuration defaults to 0. ${index2}, ${index3}, and ${index4} can be left blank. Example:

   • Create a Pod named video2

   ./k8s-video.sh start 2

   • Create five Pods from video1 to video5.

   ./k8s-video.sh start 1 5

   • Create five Pods from video1 to video5, enable the f2fs file format, and set the size quota for the /system partition inside the container to 10240 MB.

   ./k8s-video.sh start 1 5 1 10240

   • Create five Pods from video1 to video5, disable the f2fs file format, and set the size quota for the /system partition inside the container to 10240 MB.

   ./k8s-video.sh start 1 5 0 10240

   • Create a Pod named video2, disable the f2fs file format, and set the size quota for the /system partition inside the container to 10240 MB.

   ./k8s-video.sh start 2 2 0 10240

3. Check whether the Pods are successfully started.

   kubectl get pods -o wide

   It is expected that the STATUS column of Pods whose names start with video is Running.

   When multiple cloud phones are started, new cloud phones may fail to be launched because the Pod limit (110 by default) has been reached. You can edit the /etc/sysconfig/kubelet file on the worker node by adding --max-pods=300 to KUBELET_EXTRA_ARGS. Then, run the systemctl restart kubelet command to restart kubelet. You do not need to clear the existing containers before the restart. You can run the following command to verify that the value of Capacity.pods is 300. $NODENAME indicates the name of the worker node.

   kubectl describe node $NODENAME

4. Connect to the video stream cloud phone and container. In the NODE column, you can view the node corresponding to the Pod of the video stream cloud phone.

   kubectl get pods -o wide

   Access the video stream cloud phone based on 1.3-Accessing a Video Stream Cloud Phone. The client connection port is 8000 + ${index}, where${index} indicates the Pod ID.

   • On the master node and worker node, you can run the following command to access the container. The following uses video1 as an example:

     kubectl exec -it video1 -- sh

   • On the worker node, run the crictl ps command to view the cloud phone instance. The corresponding Pod is displayed in the NAME field. Run the following command to access the container. Replace ${CONTAINER} with the value in the first column in the crictl ps command output.

     crictl exec -it ${CONTAINER} sh

2.6 Deleting a Kubernetes Video Stream Cloud Phone Instance

Run the following commands on worker nodes:

cd /home/k8s/k8s/script
./k8s-video.sh delete ${index1} ${index2}

./k8s-video.sh delete 2 (Delete the Pod named video2.)
./k8s-video.sh delete 1 5 (Delete five Pods from video1 to video5.)

./k8s-video.sh ndelete 1 5 (Delete five Pods from video1 to video5.)

2.7 Creating a Base Data Volume

This section demonstrates how to create a base data volume for setting storage isolation and size of a container on a worker node.

1. On the worker node, run the k8s-video.sh script to start a cloud phone. The following uses video1 as an example:

   ./k8s-video.sh start 1

2. On the worker node, find the node where video1 resides.

   kubectl get pod -A -o wide

   In the command output, find the row where NAME is video1. The value in the NODE column is the node where video1 resides.

3. Pre-install required applications (such as Subway Surfers) in the cloud phone container.

4. Log in to the node where video1 resides. The base data volume is stored in /home/mount/img/video1.img. Rename the image file videobase.img and copy it to the /home/mount/img directory on each worker node. If you want to use videobase.img as the data volume, perform operations based on worker node operation 1.

3 Functional Specifications of Configuration Items

3.1 Commercial Modules of the Video Stream Engine

3.1.1 System Properties

You can configure video, audio, network functions of the video stream engine server using system properties. This section describes how to configure related properties.

Table 1 shows the system properties of commercial modules of the video stream engine. You can change property settings to configure the default commercial module running parameters.

Table 1 Property fields of commercial modules

3.1.2 Configuration Items of the Graphics Acceleration Layer

The graphics acceleration layer supports two configurable functions: GPU mock and shader cache. This section describes the configuration items and rules of the two functions, and provides configuration examples for reference.

• GPU mock: emulates the GPU vendor, GPU model, OpenGL ES version, GL_MAX capability value, and OpenGL ES extension.
• Shader cache: pre-builds shader binaries and shares cache across multiple cloud phones to cut shader compilation and linking time, thereby reducing the stuttering of large OpenGL ES applications.

You can configure the functions in the kbox_render_accelerating_configuration.xml file.

Configuration Items

Table 1 Configuration items in kbox_render_accelerating_configuration.xml

Table 2 Internal parameters of each name property value

Configuration Rules

• Both general system settings and application-specific settings are supported. The application name of general system settings is fixed to system. Application-specific settings can override general system settings. Only the GPU mock function is supported in general system settings.
• GPU mock serves as the fundamental function of other graphics acceleration layer functions. Enabling the shader cache function for an application will automatically enable GPU mock as well.

Configuration Example

<!-- Configuration Example -->
<!-- General system settings -->
<Application name="system" isEnable="false">
     <feature name="kbox.render.accelerating.gpuMock"  isEnable="false">
          <GL_RENDERER_MOCK>
               <param name="GL_RENDERER" value="Mali_G76"/>
               <param name="GL_VENDOR" value="Huawei"/>
               <param name="GL_VERSION" value="OpenGL ES 3.2 Mesa 22.1.7"/>
          </GL_RENDERER_MOCK>
     </feature>
</Application>
<!-- Application-specific settings -->
<Application name="process_name" isEnable="false">
     <feature name="kbox.render.accelerating.shaderCache"  isEnable="false">
          <GL_SHADER_CACHE>
               <param name="SHADER_CACHE_MODE" value="0"/>
               <param name="SHADER_CACHE_DIR_SIZE" value="200"/>
          </GL_SHADER_CACHE>
     </feature>
     <feature name="kbox.render.accelerating.gpuMock"  isEnable="false">
          <GL_RENDERER_MOCK>
               <param name="GL_RENDERER" value="Mali_G76"/>
               <param name="GL_VENDOR" value="Huawei"/>
               <param name="GL_VERSION" value="OpenGL ES 3.2 Mesa 22.1.7"/>
          </GL_RENDERER_MOCK>
          <GL_EXTENSION_MOCK>
               <param name="GL_EXT_blend_minmax" value="1"/>
          </GL_EXTENSION_MOCK>
          <GL_MAX_VALUE_MOCK>
               <param name="GL_MAX_VERTEX_ATTRIBS" value="16"/>
          </GL_MAX_VALUE_MOCK>
     </feature>
</Application>

3.2 Non-commercial Modules of the Video Stream Engine

3.2.1 Configuration Items in the Startup Script

You can configure video stream engine server functions such as hardware decoding by setting configuration items in the startup script cfct_config. This section describes the default configuration items in this file.

Table 1 describes the default configuration items in the video stream startup script cfct_config for non-commercial modules.

Configure the default running parameters for audio and video modules of the video stream engine based on this table.

Table 1 Configuration items in the script

3.2.2 Video Stream Engine Property Configuration Items

This section describes the system properties of non-commercial modules of the video stream engine, such as the video and audio modules. You can change property settings in the default.prop file to configure the default running parameters of these modules.

Table 1 describes the system properties of non-commercial modules of the video stream engine.

Table 1 Property fields of the video stream engine

3.2.3 Dynamic CPU Frequency Regulation Within Containers

3.2.3.1 Background

On physical devices, the system dynamically regulates the CPU frequency to balance load and power consumption. In contrast, cloud phones run in a containerized environment relying on the host, where the underlying physical CPU frequency typically remains constant, differing from physical devices. The following steps describe how to implement dynamic CPU frequency regulation for cloud phones to improve emulation fidelity.

3.2.3.2 Procedure

Currently, third-party detection applications typically retrieve the current CPU frequency of a device by reading two files: scaling_cur_freq and cpuinfo_cur_freq. To enhance the emulation fidelity of cloud phone devices, both files need to be modified.

Before making modifications, ensure that you have write permissions for the relevant paths. Run the following commands inside the container to check the permissions for these paths:

ls -ld /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

ls -ld /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

If the output contains w (such as -rw-r--r--), the file owner (typically root) possesses write permissions.

If the output does not contain w (for example, the output contains -r--r--r--), the file is read-only.

Run the following command inside the container to add write (w) permissions to scaling_cur_freq:

chmod u+w /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

Run the following command inside the container to add write (w) permissions to cpuinfo_cur_freq:

chmod u+w /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

Then, run the following command inside the container to read the list of supported CPU frequencies:

cat /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_available_frequencies

Next, run the following two commands inside the container to modify the frequencies. It is recommended that the input frequency values match one of the supported CPU frequencies retrieved in the previous step.

echo ${target_frequency} > /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/scaling_cur_freq

echo ${target_frequency} > /sys/devices/system/cpu/cpu${cpu_id}/cpufreq/cpuinfo_cur_freq

If the container restarts, the previous modifications will become invalid, and the CPU frequency values will restore to defaults.

To achieve dynamic CPU frequency regulation, you can copy and paste the following shell script to any path inside the container and execute it. This allows you to observe dynamic CPU frequency changes in third-party applications (such as "Device Info"). In this script, sleep 1 specifies a 1-second interval between changes, which can be modified as required. The FREQS array stores the potential CPU frequency values, and CPU_ID specifies the index of the CPU to be modified. These three values can be adjusted based on your actual requirements.

CPU_ID=0
FREQS=(554000 860000 956000 1042000 1128000 1224000 1320000 1397000 1512000 1628000 1748000 1858000 1954000)

while true; do
   for FREQ in "${FREQS[@]}"; do
      echo $FREQ > /sys/devices/system/cpu/cpu${CPU_ID}/cpufreq/scaling_cur_freq 2>/dev/null
      echo $FREQ > /sys/devices/system/cpu/cpu${CPU_ID}/cpufreq/cpuinfo_cur_freq 2>/dev/null
      echo "CPU${CPU_ID} frequency dynamically regulated to: $FREQ"
      sleep 1
   done
done

3.2.3.3 Verifying Whether the Configuration Takes Effect

After starting the container, install a third-party application (such as "Device Info") inside the container to check whether the CPU frequency matches the expected value. If it matches, the CPU frequency regulation has successfully taken effect.

4 Troubleshooting

4.1 Overview

4.1.1 Troubleshooting Principles

• Fault analysis, locating, and troubleshooting principles:

  • Restore services as soon as possible.
  • Collect fault data immediately and save the data to mobile storage media or other computers.
  • Before crafting a troubleshooting solution, evaluate the impact to ensure service continuity.
  • If a fault occurs on a third-party hardware device, view the documentation of the device or call the service hotline of the third party for assistance.
  • If a fault cannot be located or rectified according to the manual, contact technical support in a timely manner to minimize the service interruption time.

• Precautions:

  • Strictly comply with operation regulations and industrial safety regulations to ensure personnel and equipment safety.
  • Analyze the fault symptom, identify the cause, and then rectify the fault. If the cause is unknown, do not perform operations to prevent the fault from worsening.
  • Before rectifying a fault, keep all on-site records relevant to the fault and do not delete any data or logs.
  • To ensure customer network security and privacy, obtain the customer's consent and authorization before collecting fault logs.
  • Before making any modifications, back up data manually or using a script.
  • Take electrostatic discharge (ESD) prevention measures, for example, wearing an ESD wrist strap when replacing or maintaining devices.
  • Record original information in detail when any problem occurs during maintenance.
  • All major operations such as restarting processes must be documented. In addition, these operations must be performed by qualified personnel who have confirmed the feasibility of the operations, backed up necessary files, and taken contingency and security measures.
  • When the system recovers, check the system running status to confirm that the fault has been rectified. Write associated troubleshooting reports in a timely manner.
  • Exercise caution when performing risky operations and running risky commands.

• Requirements for maintenance personnel:

  • Have basic knowledge of network devices, OSs, and databases, and be skilled at running common commands for maintenance.
  • Understand the logical structure of the on-site service system, mapping relationship between components and on-site devices, and physical connections between on-site devices.
  • Be familiar with the service processes and system structure and be skilled at operating the software and hardware related to a specific service.
  • Know how to locate and rectify common faults.
  • Be adept with remote access.

4.1.2 Troubleshooting Process

The troubleshooting process consists of the following operations: collecting fault information, diagnosing the fault, locating the fault, and rectifying the fault.

Figure 1 Troubleshooting process

Fault Information Collection

Collect as much fault information as possible to facilitate fault location and rectification, such as Logcat logs in AOSP.

Fault Diagnosis

Determine the type and scope of the fault based on the collected information.

Fault Location

Identify the possible causes of the fault. You need to analyze and compare the possible causes of the fault and determine the root cause.

The commonly used methods for fault location are as follows:

• View client logs, especially the alarms.
• View server logs, especially the alarms.
• View OS logs, especially the alarms.
• Check the resource usage, especially the full load and overload of resources.
• Check operation logs for misoperations.
• View configuration files and check whether configurations are correct.

Fault Rectification

Fault rectification refers to the process of rectifying a fault according to different causes of the fault. This process involves checking and repairing devices, modifying configurations, and restarting processes, containers, and servers.

4.2 Information Collection

4.2.1 Statement

Observe the following principles during information collection:

• Perform maintenance operations only after receiving explicit approval from the customer. Any operation without explicit customer approval is prohibited.
• Do not transfer fault locating data out of the customer's network without the customer's approval.

4.2.2 Basic Information Collection

Collecting Site Information

After a fault occurs, collect site information for technical support and R&D engineers to learn about the site. In addition, provide the phone numbers of onsite engineers to ensure smooth communication.

The following table lists the site information to be collected.

Table 1 Site information to be collected

Collecting Basic Fault Information

Collect basic fault information to learn about the site, current device status, device status before the fault occurred, and possible causes of the fault. For details, see the following table.

Table 2 Basic fault information to be collected

Collecting Fault-related Alarm Information

Collect alarm information related to the fault for further analyzing, locating, and rectifying the fault. For details, see the following table.

Table 3 Alarm information to be collected

Collecting Log Information

Collect system logs and view details about user operations and operation time in the system to analyze and locate the fault.