In-depth Analysis of Softswitch Network Architecture Technology
The concept of softswitch was first proposed in 1997 and quickly gained widespread attention and recognition within the industry.
Over the following years, driven jointly by numerous manufacturers and operators, softswitch products have gradually matured, with increasingly rich functionality and steadily improving performance. Standardization efforts are advancing steadily, and softswitch technology is moving toward the market.
To date, multiple telecom operators worldwide have actively carried out experiments and commercial deployments of softswitch technology. In North America, 67% of local exchange carriers have already deployed softswitch, and 43% of long-distance exchange carriers have also deployed softswitch systems. In Europe, operators have adopted a relatively cautious approach to the development and application of softswitch, but as the technology matures, European operators have accelerated their implementation pace. In the Asia-Pacific region, operators in Hong Kong, New Zealand, Australia, Japan, and South Korea are at the forefront of softswitch application. Since 2000, China's telecommunications industry has also paid great attention to softswitch network technology, with China Telecom, China Netcom, China Unicom, China Tietong, China Satcom, and China Mobile all having fully launched softswitch application trials and commercial deployments.
Technical testing and commercial deployment of softswitch networks by various operators have proven that the softswitch architecture is essentially mature in both functionality and performance. Current issues are mainly concentrated in the following areas:
◆ As softswitch networks gradually replace PSTN networks, what mode should the system adopt for large-scale networking?
◆ How to mitigate the high autonomy of IP network users and achieve telecom operators' manageability of services?
◆ Compared to circuit-switched networks that are closed and use dedicated systems, softswitch networks built on IP networks are vulnerable to external intrusion and face security challenges. How can the security of network nodes, user information, and services be ensured?
◆ How to provide end-to-end real-time services with QoS guarantees?
◆ For users within enterprise private networks, how can services traverse enterprise NAT devices and firewalls?
To address the above issues, and considering that the IP network itself still requires considerable time to thoroughly resolve security and QoS problems, this article introduces new network elements based on the existing softswitch network and proposes a new networking approach. This networking solution helps advance softswitch networks toward commercial deployment and facilitates traditional operators' near-term commercial deployment of softswitch networks.
Networking Solution Introduction
1. Network Architecture
The network architecture is shown in the figure below:
To better solve the softswitch networking problem, this solution introduces a centralized user database HLR and a centralized routing server RS, separating user data and routing data originally stored in each softswitch device (SS) and centrally storing them in the HLR and RS, while the SS retains only information related to gateway resources, such as the idle status of E1 resources on trunk gateways.
To better address network and service security as well as QoS issues, this solution introduces a dedicated bearer network for (softswitch services) with certain security and QoS guarantees at the transport layer, along with softswitch service edge access control devices (BAC). Softswitch devices, trunk media gateways (TG), integrated access media gateways (AG), signaling gateways (SG), IADs used by important customers, media servers (MS), and BAC devices are deployed based on a dedicated network. This dedicated network can be a newly built private network or a virtual private network using technologies such as MPLS VPN, enabling mutual communication between softswitch devices and message isolation between softswitch and non-softswitch devices through various means. For IADs used by non-important customers and SIP soft/hard terminals, due to their large quantity and wide distribution, they will rapidly converge to BAC devices through various access methods, achieving interworking with other devices in the dedicated network through BAC devices. In this case, BAC provides signaling and media proxy functions as well as security detection and isolation functions.
For IAD and SIP users accessing the softswitch network through the public Internet, when a user initiates a service request, the terminal first performs DNS resolution of the SS domain name in the softswitch network, obtaining the BAC IP address assigned based on the user's location or IP address segment. The terminal sends the call request to this BAC, which checks whether the user is on the list of users who have passed security registration. If so, it performs signaling proxy between the user and the softswitch (from the user's perspective, BAC appears as the softswitch; from the softswitch's perspective, BAC appears as the user). BAC forwards the call request to the appropriate SS for processing according to preset rules.
For TG, AG, and some IAD devices deployed on the dedicated network, when a user initiates a service request, the gateway device sends the call to the corresponding SS based on the preset SS IP address.
The calling SS first queries the HLR for the user's service-related information, determines whether the user is authorized for the service and whether preset service trigger conditions are met, then accesses the RS based on the query results to obtain routing information for this call, and connects the call to the next-hop SS or service platform. The called SS receives the call request, queries the HLR to obtain the IP address of the user's designated terminal, and connects to the terminal.
2. Device Description
Regarding RS
In the early stage of network development, softswitch devices are not hierarchically graded, and the network structure between them is a logical mesh. Any softswitch device in the network stores routing information for the entire network and can directly locate another softswitch device. Within the same operator's network, softswitches are not hierarchically graded. When interworking with other operators' networks, inter-network interface SS and inter-network interface trunk gateways will be deployed.
As the network scale expands and the number of softswitch devices increases, location server devices will be introduced to implement routing queries between softswitches. The routing server accepts addressing requests from the calling SS, obtains the called SS address through data queries or by sending addressing requests to other routing servers, and returns it to the calling SS, without transmitting call control signaling.
Initially, RS can be non-hierarchical, and as the network scale expands, a hierarchical structure can be adopted. When SS routing data changes, the changes should be proactively updated to the RS. RS devices can achieve dynamic automatic updates of routing data between each other. For routing data changes of SS devices within other RS jurisdictions, there is no need to modify the routing data of SS devices in that area—only the routing data in the routing server needs to be adjusted.
The RS will store routing information mapped from called numbers, which can be the IP address of the next-hop SS, the IP address of the next-hop RS, or the address information of multiple terminals registered under a broadband user account, along with the sequential/parallel ringing order.
Regarding HLR
As is well known, the intelligence level of mobile networks is higher than that of PSTN networks, and the contribution of HLR cannot be overlooked. A new network such as softswitch should learn from the successful aspects of other networks by introducing a centralized user database into the network for centralized management of user data. Internally, it can store the service attributes of narrowband and broadband users within the managed area (such as service permissions, service user attribute trigger conditions, etc.). Due to the existence of HLR, called-side services can be triggered on the calling side; user data can be centrally stored in one location, solving the problem where, with distributed user databases, user service data modified during softswitch remote mutual backup could not be synchronized to the backup softswitch in real time.
HLR adopts multi-machine backup to improve its own reliability.
Regarding BAC Devices
The softswitch service edge access control (BAC) device is introduced to solve network security, QoS, and private network traversal issues. Its main functions include:
(1) Service traversal function
The device supports service traversal when either the softswitch user or the softswitch device is in a private network, or when both parties are in different private networks.
The device supports traversal of the user registration process without altering the registration process. User authentication and authorization are performed by the softswitch.
The device supports traversal of all services provided by the softswitch without changing service flows or introducing service security risks.
(2) Security protection function
The device can shield the addresses of softswitch devices, trunk media gateways, integrated access media gateways, media servers, and other devices from end users, protecting important network elements.
The device has packet-filtering firewall functionality to isolate network-layer attacks.
The device can block unauthorized protocol access to softswitch devices.
The device can provide simple application-layer attack protection, implementing partial proxy-type firewall functionality.
The device can shield the addresses of communication peers based on service needs, user security requirements, and operational requirements.
(3) Quality of Service (QoS) guarantee function
The device can identify, mark, and re-mark the ToS/CoS of messages entering and leaving the device, and can perform QoS processing based on marked priorities.
The device supports link QoS parameter detection functionality and can report QoS parameter statistics results to the softswitch or other designated devices in real time.
(4) Service control and management function
It can cooperate with the softswitch for service and call control, and can assist in collecting and reporting user parameters needed by the softswitch for call processing.
It supports control and management of media streams, enabling media relay control, statistics, analysis, monitoring, filtering, bandwidth control, and other functions.
(5) User management function
The device can cooperate with terminals to perform user liveness detection and report the detection results to the softswitch for processing.
In network organization, BAC devices can be placed at the metropolitan area network aggregation layer or access layer depending on user volume. Multiple BAC devices back up each other. When one device is attacked and stops providing service, DNS resolution can direct traffic to other BAC devices on the network to take over service provision, and backup is not restricted by the BAC device's network location.
3. Problems Solved
Network Congestion Control
For newly built dedicated networks, bandwidth planning can be performed, and combined with the SS's call count control function, network call congestion control can be achieved.
First, the total data bandwidth available for softswitch services between two locations is pre-planned; based on the total bandwidth and service types, the total number of simultaneous connections S that can be supported is calculated. When a call request arrives at the SS, the SS first determines whether S is currently 0. If S=0, the new call is rejected; if S>0, processing continues. When the SS completes a service connection, S=S-1.
If the data bandwidth between two locations changes, the SS should be notified to correct the total connection count S.
Regarding SS Reliability
For SS devices responsible for narrowband domain call control, a primary/standby dual-machine working mode is adopted. User data for controlled users is centrally stored in the HLR, and routing data is centrally stored in the RS. Both the primary and standby machines can access this data after activation. As for gateway resource-related data used by the SS, backups must be pre-maintained in the standby machine. This approach achieves SS reliability through resource idle redundancy.
For SS devices responsible for broadband domain call control, the aforementioned primary/standby dual-machine working mode can be adopted, but for higher equipment utilization efficiency, a multi-machine load-sharing working mode can also be used. Each BAC is responsible for distributing control information to n SS devices (such as using multiple SS devices for load-sharing processing of broadband domain services within the same province). When it receives a call request from a SIP user, it distributes the request according to preset traffic allocation principles (such as round-robin). Each SS has its own IP address, but only disclosed to the BAC. These SS devices have identical functions: processing call requests from the BAC, querying the unified HLR for user service attribute information and user status, and querying the RS for user IP addresses for routing or the next-hop SS or service platform, to achieve service connection and control. When a particular SS fails, it will affect the current call processing, and the next new call request will be processed by other SS devices. The network's service processing capacity will lose 1/n, but there is no need to leave part of the SS resources idle.
BAC implements dynamic distribution of call control information to SS devices, with protocol parsing capabilities. It can identify which messages belong to the same call based on application protocol parameters and distribute them to the same SS for call processing. BAC's own reliability is ensured through multi-machine backup.
For devices deployed on the dedicated network, such as signaling gateways, trunk gateways, high-capacity user integrated access gateways, and IADs/small-capacity user integrated access gateways used by important customers, the capability to set a backup SS address locally should be supported. When the primary SS fails and exits service, subsequent new call requests should be sent to the backup SS for processing.
For SIP users and IAD terminals deployed over the public Internet, only the domain names of the softswitch devices or various management and application servers (such as the IAD network management system, file servers, etc.) that need to be accessed are configured on the user side, rather than IP addresses. The domain names are resolved by the DNS resolver in the softswitch network, which returns the address of the corresponding BAC device. Upon receiving a call request, the BAC first determines the user type (by protocol type or whether a host name is present). For call requests from IAD users, the BAC directs the call to the primary SS based on preset values; for call requests from SIP users, the BAC distributes calls evenly to one of a group of SS devices based on preset principles (such as round-robin).
Resolution of Security Issues
First, devices such as softswitches, trunk media gateways, integrated access media gateways, and media servers are deployed on a dedicated network, which may be a newly built private network or a virtual private network using technologies such as MPLS VPN. Various means can be employed to enable mutual communication among softswitch devices and to isolate messages between softswitch devices and non-softswitch devices. It is difficult for a large number of softswitch retail users and devices on other non-softswitch networks to directly access these softswitch network devices, greatly reducing the possibility of attacks from Internet users. Since the devices in the dedicated softswitch network have a high level of trustworthiness, attacks from users within the dedicated network can be basically avoided through signaling protocol safeguards (such as authentication) and device management measures.
For IAD and SIP soft/hard terminals used by non-critical customers, due to the large number and wide distribution of these devices, they will rapidly converge on BAC devices through various access methods, and interconnect with other devices in the dedicated network through the BAC devices. In this case, the BAC provides signaling and media proxy functions as well as security detection and isolation functions. Since IAD and SIP terminals are distributed on the user side, they pose a significant security threat to the core softswitch devices. Therefore, in this solution, the operator should adopt a zero-configuration approach for IAD or SIP terminals. The operator is responsible for the configuration of all network and user data as well as subsequent updates and modifications, and users cannot modify data on their own. On the user side, only the domain names of the softswitch devices or various management and application servers (such as the IAD network management system, file servers, etc.) that need to be accessed are configured, rather than IP addresses, to avoid exposing SS IP addresses to illegal attacks.
Encryption and authentication mechanisms are enabled in the signaling protocol, and the SS periodically verifies the legitimacy of user identities to ensure the SS's control over gateways and users, preventing illegal users from stealing or interfering with services.
Through the domain name resolution mechanism and the full proxy function of the BAC device for signaling and media, the addresses of softswitches, trunk media gateways, integrated access media gateways, media servers, and other devices are shielded from users accessing via the public Internet, thereby protecting important softswitch network devices.
The BAC supports Access Control List (ACL) functionality, which can set access control rules based on source/destination IP addresses and port numbers for packet filtering; it can perform packet filtering for specific control protocols to block illegal devices and unauthorized protocols from accessing softswitch devices; it can provide simple application-layer attack protection and implement partial proxy-type firewall functions, specifically including: processing messages based on user registration status, discarding non-registration messages sent by unregistered users; establishing a monitoring list for user terminals that fail registration authentication, and taking corresponding measures when failed registration attempts reach a certain frequency; setting the allowable normal signaling message traffic threshold for IP addresses/ports, and when messages from the same source IP and port within one minute exceed this threshold, adding the address/port to a blacklist and taking corresponding measures.
It has the capability to shield the addresses of communication peers based on business needs, user security requirements, and operational requirements.
To support the implementation of a secure softswitch network, each device needs corresponding improvements, such as supporting multiple network segments, which can be achieved by providing multiple separate physical ports or supporting multiple VLANs on one physical port; dynamically opening and closing media ports; enabling minimal port configuration; user-facing services can be delivered through Web or Portal interfaces to reduce risk through service proxy methods; devices require dedicated software/hardware platform design, etc.
Resolution of QoS Issues
Current IP network technologies cannot completely resolve QoS issues, and existing public IP networks cannot provide large-scale QoS-guaranteed bearer services for softswitch networks. This solution will address QoS issues to a certain extent through a dedicated network plus the BAC's full proxy function for signaling and media.
Dedicated network deployment can adopt leased lines, dedicated IP networks, MPLS VPN, and other methods. The MPLS VPN approach still requires the support of all-IP network devices to provide QoS guarantees, and current IP networks cannot provide end-to-end QoS across the entire network. The leased line and dedicated IP network approaches can organize the network according to softswitch service requirements through network traffic prediction and planning. Since the dedicated network is used exclusively for this purpose, changes in service traffic and flow direction are easy to monitor during operation, allowing timely network adjustments. Combined with the call number control function of softswitch devices, network congestion control issues can be effectively resolved. If a new dedicated network is built, device QoS functions can be considered uniformly when procuring network equipment, differentiating softswitch services by service class and setting bandwidth reservations for certain services.
The full proxy device can perform QoS marking for signaling and media separately based on different users and different services, providing assistance for subsequent QoS processing by IP network devices. In future QoS solutions, this device can also accept instructions from softswitch devices or other QoS control devices, and perform different subsequent processing (such as continuation, rejection, redirection, codec changes, etc.) during the call setup phase based on user QoS requirements and network QoS conditions.
Prevention of Illegal Service Bypass
SIP soft terminal users who load certain SIP communication software on PCs can access the operator's softswitch system from anywhere in the world through Internet connectivity to implement communication functions. When a user uses a soft terminal in a remote location to call other users in the user's home area, the operator can only collect fees for the local call and cannot collect international or domestic long-distance call revenue. In addition, certain terminal software may, after obtaining the address information of the called party returned by the SS, stop further interaction with the SS and use other IP telephony software to communicate directly with the called party using the obtained address, causing the operator to help complete user addressing while the traffic is bypassed and revenue is lost.
The above issues can be improved to a certain extent through the BAC.
For the first issue, the approach is that the terminal is only configured with the softswitch domain name, which is resolved through DNS to the SBC it should belong to; the SBC sends its own IP address and the user's IP address to the softswitch; the softswitch performs IP address analysis to determine whether the user's IP address matches the IP address of the BAC being used. If they match, the call continues; if they do not match, the call is rejected. Of course, the premise of this solution is that the SS already understands the distribution correspondence between IP addresses and geographic regions.
For the second issue, the approach is to shield the addresses of communication peers from both signaling and media through the BAC device, which can effectively prevent service bypass and meet the special requirements of certain services (such as anonymous chat). This function is recommended to be implemented by edge service access devices.
Conclusion
The BAC, a key component in this solution, has completed the formulation of enterprise equipment specifications, including product functions, performance, and related protocol extensions, and has been submitted for project approval at the Communications Standards Association of the Ministry of Information Industry. Some equipment manufacturers have already recognized the importance of this device and have completed its development.