Design and implementation of 3G wireless video terminal based on embedded Linux

Abstract: Based on embedded system development and 3G related technologies, ARM+Linux is used as the software and hardware development platform, and the rich software and hardware resources of ARM and Linux systems are fully utilized to design and implement a 3G wireless video terminal based on embedded Linux. In terms of software design, the Linux Netfilter architecture and socket are combined, and the kernel buffer mechanism is introduced to achieve the transfer of the data packet acquisition function from the user state to the kernel state, realize the acquisition and efficient forwarding of data packets in the Linux kernel state, and solve the data packet loss problem caused by the dial-up delay of the 3G module and the mismatch between the rate generated by the video server. At the same time, a driver is developed for the 3G module under embedded Linux.
Keywords: embedded Linux; 3G; Netfilter; wireless terminal; socket

With the rapid development of network technology and embedded technology, video surveillance through the network has been widely used. The 3G network makes it possible to transmit smooth video information with its high bandwidth. This paper designs a wireless terminal based on embedded Linux based on 3G technology. The Linux Netfilter architecture is used in the data processing part. The hook function is mounted to realize the acquisition and efficient forwarding of data packets in the kernel state. In addition, a buffer is opened in the Linux kernel to solve the rate mismatch problem caused by the dial-up delay between the video server and the 3G module, reducing data packet loss. With the use of the Netfilter user state management tool iptables, packet filtering firewall, NAT and other functions can be realized, so that the system can manage the data packets passing through it.
On the other hand, the design of the embedded Linux video acquisition program is introduced in detail, and it is actually applied to the data acquisition module of this system to complete the data acquisition work. At the same time, in view of the current situation that the 3G module in the market usually only provides drivers under Windows CE, a 3G module driver under the embedded Linux system is developed. In software design, the advantages of open source software are fully utilized, and the efficient Xvidcore codec library is used to complete the video encoding, and the PPP source code is used to compile the dial-up Internet access tool. The cost is low and the system development cycle is shortened, making this system have a strong engineering practical value.

1 System hardware structure
The hardware adopts the "ARM+3G module" system architecture. The ARM and 3G modules adopt the design method of separate modules and are connected through USB cables. Compared with the overall design, it has better flexibility, so that some existing systems with ARM as the main processor can well expand the 3G function and facilitate the transition of products. The core processor of this system is S3C2440A, which is a 16/32-bit RISC microprocessor based on the ARM920T core launched by SamSu-ng Semiconductor. It has a full-performance MMU (memory processing unit) with a main frequency of 400MHz and a maximum of 533MHz. It also provides a digital camera interface. It has excellent features such as high performance, low power consumption, rich interfaces and small size. The core component of the 3G module is the MC8630 module, which has functions such as voice, SMS and high-speed data services. It can be widely used in high-speed data transmission, security, wireless media, repeater monitoring, railway terminals and vehicle-mounted monitoring.
The system hardware structure is shown in Figure 1.

2 System software design
The system is mainly composed of video acquisition module, data processing module and network forwarding module.
2.1 Video acquisition module design
According to the actual needs of the project, there are two main sources of video data in this system:
1) The system is directly connected to the video server that can provide active upload function through RJ45 network cable, which is mainly used to complete multi-channel video image acquisition. The main function of the video server is to encode and compress the data collected by the camera, and send the compressed data to the receiving end in the form of IP packets. Since this type of video server is usually used in a local area network, there is currently little support for 3G networks. With the continuous deepening of 3G technology in China, it will largely replace wired networks. Therefore, this system can be used as a 3G function expansion of existing video servers. Aiming at the problem that when connecting to an external video server, only the received data packets need to be forwarded without analyzing and processing the IP data itself, and there will be a certain delay between the system startup and the 3G module dialing successfully obtaining the IP address, this system proposes a method of using the Linux Netfilter architecture and a buffer mechanism. By mounting a hook function when the data flows through the TCP/IP protocol stack, the IP data is obtained in the kernel state, and a sufficiently large circular buffer is opened in the kernel to store the data. Since the system needs to read and write the buffer frequently, in order to avoid memory fragmentation, a circular queue data structure is used in this system. After the 3G module obtains the IP address, the data in the buffer is read by the driver, and the 3G network completes the forwarding, thereby reducing the packet loss rate and improving the forwarding efficiency of the data packet. Because the traditional method uses socket API for network programming, its access to data usually occurs in user state. For the Linux operating system, the priority of user processes and the CPU time they occupy are much smaller than kernel threads. At the same time, kernel processes have a higher execution priority. Therefore, under the condition that the network layout allows the acquisition of IP packets, the packet acquisition function of user state is loaded into kernel state, which can further improve the processing capacity of the system and increase the effective bandwidth of the system. This method can also be used in other systems that process IP data itself and have strict requirements on processing efficiency. For example, this method has also been successfully applied to the IP-TS protocol converter developed by our laboratory in cooperation with an aviation institute, and has certain versatility. Netfilter is a set of packet filtering frameworks provided by the Linux 2.6. x series kernel. Software based on this framework can implement functions such as packet filtering and network address translation (NAT). To use Netfilter, set the "Network Packet Fihering" option when compiling the kernel. Netfilter provides an abstract and generalized framework as a middleware to define a set of hook functions for each network protocol (IPv4, IPv6, etc.). Five hook functions are defined for the IPv4 protocol. These hook functions are called at five key points when the datagram flows through the protocol stack. Netfilter can capture data packets at several well-defined points in the path through the TCP/IP protocol stack. The process of an IPv4 data packet passing through the netfilter system is shown in Figure 2.

NF_IP_PRE_ROUTING This is the final hook
after which packets are transmitted. NF_IP_LOCAL_IN
This is the final hook after which packets are transmitted. NF_IP_FORWARD This is the final hook after which packets are transmitted .

The kernel netfilter structure is defined in /usr/src/inelude/linux/netfilter.h and looks like this:

The parameters are:
list
Netfilter itself is a hook chain; it points to the head of the netfilter hooks and is usually set to {NULL, NULL}.
hook
This function is called when a packet hits a hook point. This function is the same as the one described previously, it must return NF_ACCEPT, NF_DROP, or NF_QUEUE. If NF_ACCEPT is returned, the next hook is attached to the point where it will be called. If NF_DROP is returned, the packet is dropped. If NF_QUEUE is returned, the packet is queued. The sk_buff pointer is passed into this function and filled with packet information such as IP header, TCP header, etc. The sk_buff structure pointer can be used to manipulate or delete the packet (to delete a packet, just set the skb pointer to NULL).
pf
protocol family; for example, PF_INET for IPv4.
hooknum is
the hook's mount point. Since this system does not need to process the data packet locally, the selected mount point is NF_IP_PRE_ROUTING. After checking the correctness of the data packet, the hook function is called to process the data packet. Priority indicates the priority of the hook. In this system, the high priority is NF_IP_PRI_FIRST.
The key to kernel data processing is the writing of the hook function, which specifies the processing process that needs to be performed when the data packet arrives.
The hook function framework is as follows:

After setting a specific hook function, call the function
int nf_register_hook(struct nf_hook_ops*req);
to register the hook function to the kernel. Once the structure is registered in the kernel, Linux will call the function defined here to process the data packet.
Use the function
void nf_unregister_hook(struct nf_hook_ops*req);
to cancel the hook function that has been registered in the kernel. At this time, the received data packet will be processed according to the kernel's default rules. The process is shown in Figure 3.

2) Directly use CMOS camera as video acquisition device In terms of hardware, the video acquisition module S3C2440 has a CMOS camera interface, which is brought out on the development board through an interface called CAMERA, and has a camera controller. In this system, the OmniVision OV9650 camera is used. S3C2440 supports digital image input in ITU-R BT601/656 format and supports 2 channels of DMA, Preview channel and Codec channel, see Figure 4.

The preview channel can convert YCbCr4:2:2 format images into RGB (16bit or 24bit) format data and store them in the memory allocated for the preview DMA, with a maximum resolution of 640×480. It is mainly used for local LCD display. The codec channel can output YCbCr4:2:0 or YCbCr4:2:2 format to the memory allocated for the codec DMA. The maximum resolution is 4 096x4 096, which is mainly used for image encoding and decoding. The codec channel is used in this system.
The design of the video acquisition module adopts V4L2 (Video for Linux Two). V4L2 is a set of specifications for developing video acquisition device drivers under Linux. The specification adopts a layered approach to provide a clear model and consistent interface for the development of drivers, and also provides a series of interface functions for the application programming of video devices. Among them, the application is at the top layer, V4L2 is in the middle layer, and the actual hardware device is at the bottom layer. It itself includes two layers of driver structure, the upper layer is the videodev module, and the lower layer is the V4L2 driver. Video-dev calls the V4L2 driver through the member function of the V4L2 driver. During the driver initialization process of the V4L2 driver, it first enumerates the devices in the system to be processed, fills the struct v412_device structure for each device, and passes the pointer to the structure to the v412_register_device() function, which calls the initialization function in the v4L2_deviee structure to initialize the device. When the v412 driver is initialized, v412 completes the registration of the device to be processed in videodev by passing a structure containing the driver member function, the minor device number and related information to videodev. When the application triggers a driver through a system call, the control is first passed to the function in videodev. Videodev converts the file or i-node structure pointer passed by the application into the corresponding v412 structure pointer and calls the processing function in v412. Taking the OV9650 camera in this system as an example, its driver framework is shown in Figure 5.

The video acquisition process is as follows. The application first opens the video device file. The device file corresponding to the camera in the system is /dev/camera. The device is opened by calling the system "open("/dev/camera", O_RDWR)" function to obtain a file descriptor fd. The ioctl(fd, VIDIOCGPICT, &capability) function is used to obtain relevant information of the camera, such as the device name, the maximum and minimum resolutions supported, signal source information, etc., and fill them in the structure video_capability. By calling ioctl(fd, VIDIOCGPICT, &pict-ure), relevant information of the image such as the contrast, brightness, palette and other attributes of the captured image are obtained, and filled in the video_picture structure. After obtaining this type of information, it can be reassigned according to actual needs. The specific method is to assign the value to be set to the corresponding structure, and then write it to the device through the system call ioctl(fd, VIDIOCSPICT, &) function. In the image acquisition method, the mmap() system call is used to implement memory mapping to achieve the purpose of sharing the inner layer among processes. An obvious benefit of using shared memory communication is high efficiency, because the process can directly read and write memory without any data copying. To use the mmap method to obtain image data, you need to first set the buffer structure of the image frame, that is, struct video_mmap, such as the number of frames collected each time, image height, width, image palette format, etc. Then call ioctl(fd, VIDIOCMCAPTURE, &grab_buf) to start the capture process. Call iotcl(fd, VI-DIOCSYNC, &frame) to wait for the acquisition to be completed. If the function returns successfully, it means that the acquisition is completed. The acquired image will be placed in the memory area mapped by mmap(). Reading the memory data can obtain the image data, where frame is the number of frames currently intercepted. V4L2 allows multiple frames of data to be collected at a time, which can be achieved by setting grab buf. frame. Call the close(fd) function to close the device file and terminate image acquisition.
2.2 Design of video data processing module
The video images acquired by the video acquisition module need to be transmitted through the 3G network, and the amount of uncompressed data directly collected from the camera is very large. In order to improve the transmission efficiency without affecting the image quality, the original video images are compressed and encoded in this system. Since MPEG-4 is specially designed for playing high-quality videos of streaming media, and the MPEG-4 standard has become the main format and standard for network multimedia transmission with its high compression ratio, high quality and low transmission rate. It can use very narrow bandwidth to compress and transmit data through frame reconstruction technology, so as to obtain the best image quality with the least data and save small-volume video files close to DVD quality. In this system, the open source Xvidcore is selected as the core algorithm of the video compression module. Xvidcore is an efficient and easy-to-port encoding software. It not only supports Simple Profile and Advanced Profile, but also supports I/P Frames B-Frames Interlacing and GMC, and uses diamond and square modes to perform PMVFast and EPZS operation estimation. It is currently a popular MPEG-4 encoding software. Xvidcore source code can be downloaded from the Internet for free. The latest version is xvidcore-1.2.2, which provides a series of library functions and interface functions for application programs. However, for embedded system platforms, to use this library, it needs to be ported to the embedded system. The porting process is as follows:
Unzip the source code: tar-zxvf xvidcore-1.2.2. tar.gz; before use, xvidcore-1.2.2 needs to be cross-compiled, the steps are as follows:
1) Set the environment variable: export = "xvidcore current directory";
2) Enter the /build/generic directory;
3) Generate Makefrle: /configure-host = local hostbuild = arm-linux-gcc; //Specify the cross-compilation tool for cross-compilation;
4) Compile the source code: make.
Copy the library file libxvidcore.so.* generated by the cross-compilation to the cross-compiler working directory lib subdirectory. Complete the porting of the encoding library.
The above introduces the independent modules, and the overall design of the system is carried out in the software implementation, combining each module organically, and fully considering the scalability of the system.
The main structure is as follows:

Taking the video compression module as an example, its software flow is shown in Figure 6.

2.3 Network forwarding module design
After completing the compression of the captured image or receiving the video server, the data needs to be forwarded through the 3G network. The usual way to complete network data forwarding is to use the socket API provided by Linux. Socket provides users with a unified programming interface. Network transmission protocols usually include TCP and UDP. TCP needs to establish a connection through three handshakes each time, which will cause a large delay when waiting for disordered and retransmitted lost data. UDP lacks flow control, so it is not suitable for real-time data transmission. In this case, RTP running on UDP has great advantages. At present, RTP is the best protocol for data transmission with real-time requirements. Therefore, RTP protocol is used as the data transmission protocol in this system. The process is shown in Figure 7.

2.4 3G module driver design and networking
The 3G module is connected to ARM via USB. The connection between the wireless terminal and the 3G network is achieved through the PPP protocol, which is a point-to-point serial communication protocol that provides a standard method for transmitting multi-protocol data packets on a point-to-point connection. Since the 3G modules on the embedded market basically provide drivers under the Windows CE operating system, but there is currently no driver support for embedded Linux, a driver for the 3G module was developed for this system. To complete the dial-up Internet access function of the 3G module, three levels of support are required: 1) the kernel level; 2) the driver level; 3) the application level support. The kernel level is mainly completed by reconfiguring the kernel. Since the 3G module is connected to ARM via a USB cable, and the upper-level PPP communication uses a serial protocol, it is necessary to add USB to the serial port support in the kernel. Enter the kernel configuration interface through the makemenuconfig command, select Device Drivers->USB support->USB Serial Converter Support in turn, select USB Generic Serial Driver, press the space bar twice to add [*] in front of the item to compile it into the kernel, where adding * means compiling it into a kernel module and adding M means compiling it into a module. Since the PPP protocol is used, PPP support should be added to the kernel. After entering the kernel configuration interface, select DeviceDrivers->Network device support->PPP (point-to-point) protocol support in turn, compile PPP into the kernel, and select the PPP expansion item to compile it all into the kernel, save and exit. For the driver level, the driver development of the 3G module is mainly through modifying two files generic.c and usb-serial.c, where generic.c is the USB general program and usb-serial.c is the USB to serial port program. Support for the upper layer protocol is achieved by adding some network layer hook functions. Copy the modified files to /linux2.6.29/drivers/usb/serial, recompile the kernel, generate a zImage image, and then download it to the board. The design of the 3G module driver and the kernel's support for the PPP protocol are completed. The support for dial-up Internet applications is mainly achieved through the two tools pppd and chat provided by PPP. PPP provides a method for transmitting data streams on a point-to-point serial line, and chat is mainly used for dialing and waiting for prompts. PPP source code can be downloaded from the Internet. The version used in this system is PPP-2.4.0. After downloading, it needs to be unzipped and cross-compiled according to the type of target board to obtain the dial-up program.

3 Conclusion
This paper implements multiple functions on an ARM development board, including wireless data video terminal. The 3G function expansion of the existing video server is realized by connecting an external video server. By combining Netfilter with socket, the data packet acquisition function is loaded from user state to Linux kernel state, avoiding memory copy of data and improving processing efficiency. At the same time, the kernel buffer mechanism is introduced. The problem of video server packet loss caused by 3G dial-up delay is solved. With the use of Netfilter user tool iptables, NAT, packet filtering firewall and other functions can be implemented on this system. It is convenient to manage the data packets flowing through the system.
In view of the problem that most 3G modules on the market only provide drivers under Windows CE, a 3G module driver is developed, so that the existing 3G module can be used in the embedded Linux system. Users can directly program through socket on this basis without considering the underlying hardware communication problem. The software design fully utilizes the advantages of open source software, using Xvideore for video encoding and PPP source code to compile dial-up software, shortening the system development cycle. The system proposes a relatively common software architecture in the overall software design, which can facilitate the expansion and upgrading of functions.