KR100861423B1 - Universal telecommunication node with software-defined exchangeable protocol architecture - Google Patents

Abstract

The present invention proposes a network node comprising modules (1,2,3,4,5,6; 7) including transport functions to support a particular network transport protocol, wherein the transport functions are implemented by software. do. The invention also proposes a method of operating a network node. Different network transport protocols are supported on the same hardware by installing the corresponding software.

Network transport protocols, network nodes, communication protocols, interface modules.

Description

UNIVERSAL TELECOMMUNICATION NODE WITH SOFTWARE-DEFINED EXCHANGEABLE PROTOCOL ARCHITECTURE}

The present invention relates to a network node and a method for operating a network node, wherein the network node comprises at least one module.

In particular, the present invention relates to a network node comprising at least one module that performs transport functions. An example of a network such network node may be used is a WCDMA (Wideband Code Division Multiple Access) radio access network. Another example of such a network is a CDMA2000 network.

The WCDMA Radio Access Network (RAN) is specified by the third generation partnership project (3GPP releases R99, R4 and R5).

1 illustrates a broadband-CDMA radio access network and its interfaces. This figure illustrates the general structure and environment of WCDMA RANs. In particular, the WCDMA RAN includes a plurality of base stations (BTS) and a radio network controller (RNC). The WCDMA core network (CN) includes, for example, a mobile switching center (MSC) and a serving GPRS (Universal Packet Radio System) support node (SGSN).

The external interfaces are Iu, which is the interface to the Uu and WCDMA core networks. Uu is the 'air interface' for a user equipment (UE), i.e., a mobile phone having a UMTS (Universal Mobile Communication Services) SIM (Subscriber Identification Module) card. Internal interfaces are defined as Iub between RNC and BTS and Iur between RNCs.

The 3GPP protocol architecture is based on the principle that layers and planes are logically independent of each other. If necessary, some of the protocol structures may change in the future, while others may remain intact. The protocol structure consists of two main horizontal layers, an upper radio network layer (RNL) and a lower transport network layer (TNL). All WCDMA-related problems can be seen only at the wireless network layer, and the transport network layer is selected for the WCDMA RAN, but represents a standard transport technique without WCDMA RAN-specific changes.

Initially, Asynchronous Transfer Mode (ATM) is used as the transport protocol on the Iub, where Iub is the interface between the BTS (also referred to as 'Node B') and the RNC, more specifically called Iub / ATM.

This is illustrated in FIG. 2 showing the protocol stack of the Iub / ATM interface. In particular, FIG. 2 shows the protocol stack used in the case of an ATM transport network. Two horizontal layers (RNL and TNL) are shown. In terms of TNL, frames that carry data such as RNL control plane (NBAP (Node B application portion)) and RNL user plane (ie, DCH (dedicated channel), RACH (random access channel), FACH (forward access channel), etc.) Protocols) are TNL user data. AAL2 (ATM Adaptation Layer 2) signaling (Q.2630.1) is used to control ATM-based TNL, ie AAL2 connections are setup and released as needed for RNL. Signaling is sent via the signaling transport converter (STC) on the SSCOP, service specific connection oriented protocol (SSCOP), and AAL5 as shown in FIG.

In addition, 3GPP Release R5 also specifies Internet Protocol (IP) as an alternative transport protocol, which can be used in place of ATM. The interface between the BTS and RNC is called Iub / IP.

This is illustrated in FIG. 3 showing the protocol stack of the Iub / IP interface in the case of an IP transport network. For RNL this is essentially the same as ATM transmission. Here, IPC (IP Control) signaling is used to control the IP-based TNL.

3GPP also considers IP because it generally assumes that substantial cost savings (Operational Expenditure (OPEX) and Capital Expenditure (CAPEX)) can be achieved with IP in the future.

Typical BTS architectures represent the separation of the Iub into the RNL and TNL layers, which include transport blocks (TBs) and radio network layer blocks, which are divided into baseband blocks (BB) and radio frequency blocks (RFB). Can be further refined. In careful implementations, only TBs need to be exchanged when the transport protocol changes from ATM to IP.

At hub sites that collect traffic from several BTSs, standard communication nodes are typically deployed. In the ATM case, these are ATM cross-connections or routers. In the IP case, these are IP routers. Normally, an ATM node cannot be switched to an IP router, that is, if the mobile operator eventually wants to change the hub point from ATM to IP transport, it will have to replace the ATM hardware with IP hardware. Thus, at present ATM switches or cross-connects always remain ATM switches or cross-connects, and IP routers always remain IP routers. The reason is specifically designed hardware (typically, application specific integrated circuits (ASICs)) that support only one transmission protocol option.

In a typical WCDMA RAN, thousands of base stations are deployed. If the Iub / IP option becomes economically attractive in the future, the mobile operator will want to change some or all base stations of the WCDMA RAN from Iub / ATM to Iub / IP. Typically, there are also hub sites with ATM cross-connections or ATM switches. These will need to be replaced by IP routers. This move from Iub / ATM to Iub / IP becomes very expensive when major hardware changes are necessary.

Accordingly, it is an object of the present invention to change the transport protocol used for network nodes with low cost and minimal maintenance work.

This object is solved by a network node comprising at least one module comprising transport functions to support a particular network transport protocol, wherein the transport functions are implemented by software.

Alternatively, the object is solved by a method of operating a network node, wherein the network node comprises at least one module comprising transport functions to support a particular network transport protocol, said method comprising a transport function by using software. Performing the steps.

The invention also proposes a computer program product for a computer, which includes processor executable instructions for performing the method steps described above.

Thus, according to the invention, the transmission functions are implemented by software. In other words, if necessary, the software can be easily updated so that other transport protocols (eg, ATM or IP) can be handled.

Thus, no hardware exchange is needed, thereby minimizing the costs and maintenance work required for transport protocol changes.

Further advantageous developments are presented in the dependent claims.

The invention is explained below with reference to the accompanying drawings.

1 illustrates a broadband-CDMA radio access network and its interfaces.

2 shows the protocol stack of the Iub / ATM interface.

3 shows a protocol of an Iub / IP interface.

4 shows a transport block having a software-defined switchable protocol architecture according to a first preferred embodiment of the present invention.

5 illustrates a transport block having a software-defined switchable transport protocol architecture customized for ATM according to a first embodiment of the present invention.

6 shows a transport block with a software-defined switchable transport protocol architecture adapted for IP according to a first embodiment of the invention.

7 shows a single module transport block according to a second preferred embodiment of the invention.

In the following, preferred embodiments of the present invention are described.

In its general form, a network node according to embodiments of the present invention includes at least one module including transport functions to support a particular network transport protocol, wherein the transport functions are implemented by software.

That is, according to the present invention, the transmission functions are implemented by software, while the remaining modules may be implemented by hardware. However, there is no limitation to this, and some of the remaining modules (especially control functions, for example) can also be implemented by software.

Examples for modules may be interface modules, in particular, providing a connection to an external network. Another example is a central module, whose transport functions provide, for example, access to higher layers of a network node.

According to a specific example of this embodiment to be described below, the network node is a base station, which includes a transport block, a baseband block, and a radio frequency block as described below with reference to FIG. 4.

The base station can support both ATM and IP transport (3GPP Iub / ATM or Iub / IP). Whether ATM or IP is used is determined solely by the embedded software of the transport block, not by the hardware. This allows mobile operators to make in-field upgrades from ATM to IP through remote software changes without the need for very expensive site visits and hardware replacements.

The same idea may also apply to standalone ATM nodes (eg, deployed at hub sites). That is, by updating the software, standalone ATM nodes can be converted to IP routers by remote software change.

Moreover, vendors of communications equipment (e.g., base stations, ATM nodes or IP routers) can use the exact same hardware platform for ATM and IP transport solutions by customizing embedded software. have.

4 shows a transport block with a software-defined switchable transport protocol architecture. In particular, FIG. 4 shows a base station of a general model consisting of a transport block (TB), a baseband block (BB) and a radio frequency block (RFB). The transport block is shown in more detail. By way of example, four interface modules with different physical interface types are shown. The first interface module, indicated by reference numeral 1, provides an Ethernet interface. The second interface module 2 provides a PDH (similar synchronous digital hierarchy) interface. The third interface module 3 provides an SDH / SONET (synchronous digital hierarchy / synchronous optical network) interface, and the fourth interface block 4 provides a frame relay interface. The interface modules handle subordinate transmission functions, which are illustrated by the blocks 11, 21, 31 and 41 of the corresponding interface module 1-4. These are specialized for specific transport protocols (eg ATM or IP) by software.

The transport module represented by block 61 and the higher transmission functions illustrated by the block indicated by reference numeral 62 by the central module (shown in the center of the transport block) indicated by reference numeral 6. And interworking between the baseband block and the baseband block. In addition, higher transport layers and interworking functions are implemented in software. Thus, they can be adapted to the specific needs of the transport protocol used. All transport block modules (interface modules 1 to 4 and central module 6) are connected by Ethernet switch 5. However, this is merely an example for this embodiment. Other possible reason for transmitting node-internal connection methods are also feasible. That is, instead of a switch, another kind of node-internal network providing means may be used, and instead of Ethernet, another node-internal network transmission protocol may be applied.

Thus, as shown in FIG. 4, the TB consists of a central module supplemented by several interface modules. The interface modules perform lower transport layer (e.g. ATM layer or IP data link layer) and physical layer functions (e.g. PDH and SDH / SONET), while the central module performs upper transport layer functions (e.g. For example, AAL2 / AAL5 or IP routing). Moreover, according to the present embodiment, the central module 6 also performs necessary interworking functions between the TB and the BB blocks. According to this embodiment, point-to-point VLAN (Virtual Local Area Network) Ethernet is used as a universal transport mechanism within TB for the connection of interface modules with the central module.

All lower and upper transport layer functions (illustrated by blocks 11, 21, 31, 41, and 62) and interworking functions (illustrated by block 61) are performed by software on high performance processing engines. Thus, the entire transport layer and interworking functions can be exchanged by installing new software.

In the following, the architecture described above is described with reference to FIGS. 5 and 6 when the transport block is configured for ATM and when the transport block is configured for IP.

5 shows a software-defined switchable transport protocol architecture adapted for ATM. That is, FIG. 5 shows the adaptation of the configuration shown in FIG. 4 to Iub / ATM in accordance with this embodiment.

Standard ATM processing as conformance checks for traffic contracts, CLP = 1 tagging of non-conforming cells, OAM and RM cell handling, etc. are performed on the interface modules. ATM cross-connections are also handled by the interface modules. AAL2 and AAL5 processing is performed on the central module. All of this is not described in detail herein, since this is not relevant to the present invention. Depending on the particular implementation, other partitions of ATM functionality are also feasible. All ATM-related functionality is implemented in software. According to this embodiment, it is assumed that the interface between the TB and the BB is based on IP protocols, whereby an interworking function is provided that adapts the external ATM world of the transport network to the internal IP world of the base station. This interworking function is also implemented in software in the TB.

On the left side of the transport block, the ATM cross-connection provided by the interface modules 1 and 2 is shown. This ATM PVC (fixed virtual circuit) may carry traffic from other base stations that are physically connected to the base station shown to implement the RAN in a chain or star topology. This traffic is only piped through the TB and is not visible to the BB and RFB.

Specifically, in this example, the interface module 1 may include VPI_in (incoming virtual path identifier) (08 in this example), VCI_in (incoming virtual channel identifier) (15 in this example) and cell payload (Cell PL). Receive ATM cells comprising a. The ATM layer functions 11 of the interface module 1 encapsulate these ATM cells in Ethernet frames with an Ethernet header. In addition to this, VPI_out (outgoing virtual path identifier) is set (47 in this example) and VCI_out (outgoing virtual channel identifier) is set (11 in this example). The Ethernet switch 5 forwards these Ethernet frames to the interface module 2, which transmits them via the PDH interface.

On the right side of FIG. 5, the finished flow is shown. ATM cells received by the interface modules (in this example, by the interface module 4) are forwarded to the central module 6, which centrally collects the RNL frames by performing AAL processing. That is, the higher transport functions illustrated in FIG. 4 by block 62 are represented by the AAL functions here. The RNL frame is further processed by the interworking function 61, which (in accordance with this embodiment) encapsulates the frame into IP packets and forwards the IP packets to the BB. After baseband processing, the frame is forwarded to the RFB and transmitted over the air interface to the mobile station. Other directions (from the mobile station to the RAN) are similar, but are not shown here.

Thus, as shown in FIG. 5 and described above, for example, an Iub / ATM transmission option may be loaded into the TB. Later, interface modules will obtain software, which enables the modules to receive and transmit ATM cells in a physical frame. The interface modules can encapsulate ATM cells into Ethernet frames to forward the cells to another interface module (for ATM cross-connection) or to a central module (for traffic terminating at the base station). The central module performs AAL functions to recollect (and segment in the other direction) the radio network layer frames to be forwarded to the BB. The interworking function then adapts these frames to the format expected by the base station internal interface between the TB and the BB. According to this embodiment, this interface may be based on IP and Ethernet. RNL frames are mapped to UDP messages or TCP streams in this case.

6 illustrates a baseband block with a software-defined switchable transport protocol architecture adapted for IP. That is, FIG. 6 shows the adaptation of the configuration shown in FIG. 4 to Iub / IP. Standard IP data link layer processing is performed on the interface modules. IP routing is performed on the central module. This is not described in detail herein because it is not relevant to the present invention. Depending on the particular implementation, other partitions of IP functionality are also feasible. All IP-related functionality is implemented in software. Here, it is assumed that the interface between TB and BB is based on IP protocols, and thus only a null interworking function is needed.

On the left, the routed flow (eg, traffic from other base stations) is shown, and on the right, the terminated IP flow is shown.

In detail, the IP packets arrive at the interface module 1, and the lower transport function 11 with software performing the IP data link layer functions encapsulates the received IP packets into Ethernet frames. That is, Ethernet frames include an Ethernet head, an IP head, a UDP (User Datagram Protocol) head, a RNL (Radio Network Layer) head, and a Cyclic Redundancy Checksum (CRC). These Ethernet packets are forwarded by the Ethernet switch 5 to the higher transport functions 62 of the central module 6, which contain the software for the IP routing functions. In other words, in this example, the routing is performed by the central module. Thereafter, packets are forwarded to the interface module 2 via the Ethernet switch 5. The IP data link layer functions convert the Ethernet encapsulation of IP packets into another second layer encapsulation suitable for an external network, where the external network is connected to another base station, for example.

In the example of terminated traffic, interface module 4 receives IP packets to be received in the radio frequency block. IP data link layer functions 41 encapsulate incoming IP packets into Ethernet frames similar to the case of routing traffic described above. These Ethernet frames are forwarded to the Ethernet switch 5, which forwards them to the IP routing functions 62 of the central module. IP routing functions convert (eg, extract) Ethernet frames into IP packets (or other protocol packets suitable for the radio frequency block), and forward them to the transmit / baseband interworking function 61 of the central module. All.

Therefore, according to the configuration shown in Fig. 6, the Iub / IP transmission option is loaded into the TB. Afterwards, the interface modules will obtain software, which enables them to receive and transmit IP packets in a physical frame. The interface modules may encapsulate IP packets into Ethernet frames to forward the packets to a central module. The central module performs IP routing functionality and determines whether the IP packet is additionally routed to the IP network or whether the IP packet belongs to a traffic stream terminating at the base station. If the IP packet is routed, it will be sent to the interface module, and if the IP packet belongs to the terminated stream, it will be forwarded to the interworking function. The interworking function then adapts the RNL frames contained in the IP packets to the format expected by the base station internal interface between the TB and the BB. According to this embodiment, this interface may also be based on IP as in the entire RAN. In this case, the interworking function may be a null function, and TB is an IP router.

Thus, according to this embodiment, the transmission protocol used for TB can be easily changed between IP and ATM by changing the software of the lower and upper transmission functions. No hardware replacement is required.

Thus, according to this embodiment, traffic to and from the outside of the transport block is converted into a form suitable for the switch 5. That is, internally, the transport block operates with Ethernet frames that can be handled by the switch 5. The conversion between Ethernet frames and an external network protocol (eg IP or ATM) can be handled entirely through software in the underlying transport functions 11, 21, 31 and 41. Similarly, the upper transport functions 62 of the central module convert, for example, traffic received via the switch 5 into a protocol suitable for higher functions of the transport block, and vice versa. Thus, the internal Ethernet structure of the node forms a universal, immutable basis, on which various externally visible network protocols such as ATM and IP can be implemented by simply providing appropriate software.

In the case of an operator-initiated change from Iub / ATM to Iub / IP, the operator will load new software packages into the TB using TB's normal housekeeping features such as remote configuration management and software download. If base station vendors want to use the same hardware platform for ATM and IP transport, they will customize the general purpose node platform by installing the appropriate embedded software at the time of manufacture.

Software updates can be performed over the network, so no maintenance on location is required. To this end, a specific program loader can be provided which loads the new software into the corresponding interface modules and the central module.

The software may be delivered as a software package containing appropriate software binaries for each module type. Using the software management functionality of the node and network management system, software packages can be downloaded to the node via remote management connections. Thereafter, the node's software management functions can distribute the included software binaries to corresponding modules. Along with the software package, a configuration file containing the required new node settings can be downloaded. If the download is successful, the network management system can activate the new software package. After receiving the activation commands remotely, the node can start new software, for example by rebooting with new binaries. After activation, the node can automatically apply the settings defined in the configuration file. By appropriate settings in the configuration file, a node (which previously operated as an ATM cross-connection) can immediately assume a new role (eg, an IP router).

Thus, according to the present embodiment, the mobile operator can change the transport network from ATM to IP with pure software download without changing hardware. Telecommunications equipment vendors can use the exact same hardware platform for ATM and IP transport blocks and standalone transport nodes. Manageability is increased because bug fixes only require new software releases, not redesign and replacement of transport protocol-specific integrated circuits. New features can be easily modified.

According to the first embodiment, an architecture comprising a central module and additional interface modules is described. However, an architecture is also possible in which all functionality is located in a single module.

In the following, a second embodiment in which the single module transport block 7 shown in FIG. 7 is provided is described. The single module may include transmit / baseband interworking function 71, upper transport block 72 (e.g., AAL processing, IP routing), lower transport functions 73 (e.g., ATM layer, IP data link). Layer), all of which are defined by software.

Thus, the transport block according to the second embodiment does not need a switch as in the first embodiment.

In summary, according to the present invention, an implementation and mechanism (software upgrade) is provided to overcome the hardware replacement problem required when changing the transport protocol on the Iub interface in the WCDMA RAN from ATM to IP. Flexible base station hardware can support both ATM and IP transport protocols (eg, by using network processors or Field Programmable Gate Arrays (FPGAs) in the implementation). Whether ATM or IP is used is determined solely by the embedded software of the transport block, not by hardware. This allows mobile operators to upgrade BTS in-field from ATM to IP with remote software changes without the need for very expensive site visits and hardware replacements.

Thus, there are three main applications for the invention described above.

1. The transport block of the base station can be upgraded from Iub / ATM to Iub / IP through software download by the mobile operator.

2. A standalone ATM cross-connect / switch is installed in the 3G network, which needs to be switched to an IP router when the 3G network is upgraded from Iub / ATM to Iub / IP. This is also done via SW download by the mobile operator.

3. In addition to these mobile applications, there is a generic HW platform that can be used as an ATM cross-connect / switch or IP router depending on the burned-in firmware. The vendor will determine if this HW is delivered as an ATM cross-connect / switch or IP router, and the customer will not be able to change it. This is beneficial for the vendor (although not required by the customer), since the same HW platform can be used for different products.

However, the present invention is not limited to these applications.

The foregoing detailed description and the accompanying drawings illustrate the invention by way of example only. Accordingly, the above embodiments may be modified within the scope of the claims.

For example, according to the above embodiments, the network node is a base station. However, the present invention is not limited thereto. In contrast, the network node according to the present invention may be any suitable network element or unit for which transmission functions are provided. For example, the network node may include, for example, standalone ATM cross-connections or switches required at hub sites. Moreover, the network node may comprise an IP router.

That is, if the hardware is designed as described above, ATM cross-connections or switches can be converted to IP routers by remote software change.

In addition, the above embodiments relate to radio access networks. However, the present invention is also applicable to all communication or data networks that deploy ATM nodes or IP routers.

Moreover, the present invention is not limited to ATM or IP. In contrast, almost all suitable transport protocol stacks can be implemented on the same hardware platform by suitable software.

Claims (35)

A network node, comprising transport functions performed by software to support a particular network transport protocol. At least one interface module 1, 2, 3, 4; Central module 6; and Node-internal network providing means 5 for providing a connection to said at least one interface module and a central module, said node-internal network providing means 5 operating with a particular node-internal network transport protocol, The transport functions 11, 21, 31, 41, 62; 72, 73 of the at least one interface module and the central module convert the traffic according to the network transport protocol into a form suitable for the node-internal network transport protocol. Or converting the traffic according to the node-internal network transport protocol received from the node-internal network providing means into the network transmission protocol as well as receiving traffic from the node-internal network providing means. . delete delete delete delete The method of claim 1, And said node-internal network transport protocol is an Ethernet protocol. The method of claim 1, And said node-internal network providing means is a switch. The method of claim 1, Means for updating the software of the transmission function of the at least one interface module and the central module. The method of claim 8, Means for updating the software is configured such that the software can be updated remotely. The method of claim 1, The network transport protocol is an internet protocol (IP). The method of claim 1, Said network transport protocol being an asynchronous transport mode (ATM). The method of claim 1, Wherein said network node is a base station. The method of claim 1, And wherein said network node is a standalone asynchronous transfer mode (ATM) cross-connect node. The method of claim 1, The network node is an internet protocol (IP) router. The method of claim 1, And wherein said network node is a general purpose hardware platform. The method of claim 15, The general purpose hardware platform may be used as a standalone asynchronous transfer mode (ATM) cross-connect node or as an internet protocol (IP) router according to the software. A method of operating a network node, the network node comprising: at least one interface module, a central module, and at least one interface module and a central module, including transmission functions performed by using software to support a particular network transport protocol. Means for connecting node-internal network providing means 5, said node-internal network providing means 5 operating in a particular node-internal network transport protocol, said transmission function of said at least one interface module and a central module By converting the traffic according to the network protocol into a form suitable for the node-internal network transport protocol, or by using the transport function of the at least one interface module and the central module, to the node-internal network providing means. Emitter received, the Node-way network nodes, characterized in that operation of converting traffic according to the internal network transport protocol into the network transport protocol. delete delete delete delete The method of claim 17, And said node-internal network transport protocol is an Ethernet protocol. The method of claim 17, And said node-internal network providing means is a switch. The method of claim 17, Updating the software of the transmission function of the at least one interface module and the central module. The method of claim 24, And wherein said updating is performed remotely. The method of claim 17, And said network transport protocol is an internet protocol (IP). The method of claim 17, And said network transport protocol is an asynchronous transport mode (ATM) protocol. The method of claim 17, And the network node is a base station. The method of claim 17, And wherein said network node is a standalone asynchronous transfer mode (ATM) cross-connect node. The method of claim 17, And said network node is an internet protocol (IP) router. The method of claim 17, And wherein said network node is a general purpose hardware platform. The method of claim 31, wherein Said general-purpose hardware platform can be used as a standalone asynchronous transfer mode (ATM) cross-connect node or as an internet protocol (IP) router according to said software. A computer readable medium, 33. A computer readable medium containing a computer program comprising processor executable instructions for performing the methods according to one of claims 17 or 22 to 32. delete The method of claim 33, And the computer program can be loaded directly into the internal memory of the computer.

Images