1. Field of the Invention
The invention relates to a network node and a method for operating a network node, wherein the network node comprises at least module.
2. Description of the Prior Art
In particular, the invention relates to a network node comprising at least module performing transport functions. An example for a network in which such a network node may be employed is a WDCMA (Wideband Code Division Multiple Access) Radio Access Network. Another example for such a network is a CDMA2000 network.
WDCMA Radio Access Networks (RAN) are specified by the 3rd Generation Partnership Project (3GPP releases R99, R4 and R5).
The external interfaces are Iu, which is the interface to the WCDMA core network, and Uu. Uu is the ‘air interface’ to the user equipment (UE), i.e. the mobile phone with the UMTS (Universal Mobile Telecommunication Services) SIM (Subscriber Identity Module) card. The internal interfaces are defined as Iub between RNC and BTS and lur between RNCs.
The 3GPP protocol structure is based on the principle that the layers and planes are logically independent of each other. If needed, parts of the protocol structure may be changed in the future while other parts remain intact. The protocol structure consists of two main horizontal layers, the upper Radio Network Layer (RNL) and the lower Transport Network Layer (TNL). All WCDMA RAN-related issues are visible only at the Radio Network Layer, while the Transport Network Layer represents standard transport technology, which is selected for the WCDMA RAN but without WCDMA RAN-specific changes.
Initially, Asynchronous Transfer Mode (ATM) is used as transport protocol on the lub, i.e., the interface between BTS (also referred to as ‘node B’) and RNC, which is called more specifically Iub/ATM then.
This is illustrated in
In addition, 3GPP Release R5 also specifies the Internet Protocol (IP) as an alternative transport protocol, which can be used instead of ATM. The interface between BTS and RNC is then called lub/IP.
This is illustrated in
3GPP considers also IP because the general assumption is that substantial cost savings (OPEX (Operational Expenditure)) and CAPEX (Capital Expenditure)) can be achieved with IP in the future.
Typical BTS architectures reflect the separation of the lub into RNL and TNL layer: There is a transport block (TB), and there is radio network layer block, which may be further subdivided into baseband block (BB) and radio frequency block (RFB). With well-advised implementations, only the TB needs to be exchanged then when the transport protocol is changed from ATM to IP.
At hub sites aggregating traffic from several BTS, standard telecommunication nodes are typically deployed. In the ATM case, these are ATM cross-connects or switches, and in the IP case these are IP routers. Normally, an ATM node cannot be turned into an IP router, i.e. if a mobile operator eventually wants to change a hub point from ATM to IP transport, he will have to replace the ATM hardware by IP hardware. Therefore, at present ATM switch or cross-connect always remains an ATM switch or cross-connect, and an IP router always remains an IP router. The reason behind is specifically designed hardware (typically Application Specific Integrated Circuits (ASICs)), which supports only one transport protocol option.
In a typical WDCMA RAN, several thousands of base stations are deployed. If the lub/IP option becomes economically attractive in the future, a mobile operator might want to change some or all of the base stations in the WCDMA RAN from Iub/ATM to lub/IP then. Typically, there are also hub sites with ATM cross-connects or ATM switches, which need to be substituted by IP routers then. Such a migration from Iub/ATM to lub/IP is very expensive when major hardware changes are necessary.
Hence, it is an object of the present invention to allow a change of transport protocol used for a network node with low cost and a minimum maintenance work.
This object is solved by a network node as defined in the independent claim 1.
Alternatively, the object is solved by a method for operating a network node as set out in the independent claim 13.
Thus, according to the invention the transport functions are realized by software. That is, if necessary, the software can easily be updated so that another transport protocol (e.g., ATM or IP) can be handled.
Hence, no exchange of hardware is necessary, so that costs and maintenance work required for the change of the transport protocol are minimal.
Further advantageous developments are set out in the dependent claims.
The invention is described in the following by referring to the attached drawings in which:
In the following, preferred embodiments of the invention are described.
In its general form, a network node according to the present embodiments of the invention comprises at least one module including transport functions in order to support a particular network transport protocol, wherein the transport functions are realized by software.
That is, according to the invention the transport functions are realized by software, whereas the rest of the module can be realized by hardware. This is, however, not limited thereon, parts of the rest of the module (in particular, control functions, for example) may also be realized by software.
Examples for the modules may be in particular interface modules which provides a connection to an external network. Another example is a central module, the transport functions of which provide a connection to higher layers of the network node, for example.
According to a specific example of the present embodiment described in the following, the network node is a base station, which comprises a transport block, a baseband block and a radio frequency block, as described in the following by referring to
This base station can support both ATM and IP transport (3GPP Iub/ATM or lub/IP). Whether ATM or IP is used, is only determined by the embedded software of the transport block, and not by any hardware. This allows mobile operators in-field upgrade from ATM to IP via remote software change, without the need of very expensive site visits and hardware replacements.
The same idea can also be applied to standalone ATM nodes (e.g. deployed at hub sites). That is, by updating the software, the standalone ATM nodes can be transformed into IP routers by remote software change.
Furthermore, vendors of telecommunications equipment (e.g. base stations, ATM nodes or IP routers) can use exactly the same hardware platform for ATM and IP transport solutions by customizing the embedded software.
A central module (depicted in the middle of the transport block) denoted with reference numeral 6 implements higher transport functions, illustrated by a block denoted with reference numeral 62, and the inter-working between transport and baseband block, which is illustrated by block 61. Also the higher transport layer and inter-working functions are realized in software; they can thus be adapted to the particular needs of the used transport protocol. All transport block modules (interface modules 1 to 4 and central module 6) are connected via an Ethernet switch 5 here. However, this is only an example for the present embodiment: Other—possibly proprietary—transport node-internal connection methods are also feasible. That is, for the switch some other kind of node-internal network providing means can be used, and instead of Ethernet another node-internal network transport protocol may be applied.
Thus, as shown in
All lower and higher transport layer functions (illustrated by the blocks 11, 21, 31, 41 and 62) and the inter-working function (illustrated by the block 61) are implemented in software on programmable high-performance processing engines, so that the complete transport layer and the inter-working function can be exchanged by installing new software.
In the following, the architecture described above is described for the case that the transport block is configured for ATM and for the case that the transport block is configured for IP by referring to
Standard ATM processing as checking of conformance to the traffic contract, CLP=1 tagging of non-conforming cells, OAM and RM cell handling etc. is done on the interface modules. Also ATM cross-connections are handled by the interface modules. AAL2 and AAL5 processing is done on the central module. This all is not described here in detail, since it is not relevant for the invention. Depending on the particular implementation, other partitioning of the ATM functionality is also feasible. All ATM-related functionality is realized in software. According to the present embodiment, it is assumed that the interface between TB and BB is based on IP protocols, so an inter-working function is provided which adapts the outer ATM world of the transport network to the inner IP world of the base station. Also this inter-working function is realized in software in the TB.
On the left side of the transport block, an ATM cross-connection is shown, which is provided by the interface modules 1 and 2. This ATM PVC (Permanent Virtual Circuit) may carry traffic from other base stations, which are physically connected to the depicted base station, in order to realize a RAN in chain or star topology. This traffic is only piped through the TB and not visible to the BB and RFB.
In detail, in this example the interface module 1 receives ATM cells comprising a VPI_in (incoming Virtual Path Identifier) (08 in this example) and a VCI_in (incoming Virtual Channel Identifier) (15 in this example), and comprises the cell payload (Cell PL). The ATM Layer Functions 11 of the interface module 1 encapsulates these ATM cells in Ethernet frames having an Ethernet header. In addition, VPI_out (outgoing Virtual Path Identifier) is set (in this example, to 47), and VCI_out (outgoing Virtual Channel Identifier) is set (in this example, to 11). The Ethernet switch 5 forwards these Ethernet frames to the interface module 2, which sends it via the PDH interface.
On the right side in
Thus, as shown in
On the left side, a routed flow (e.g. traffic from other base stations) is shown, and on the right side, a terminated IP flow is shown.
In detail, IP packets arrive at the interface module 1, and the lower transport function 11, now having software for performing IP data link layer functions, encapsulates the received IP packets into Ethernet frames. That is, the Ethernet frames comprise an Ehternet head, the IP head, a UDP (User Datagram Protocol) head, a RNL (Radio Network Layer) head and a CRC (Cyclic Redundancy Checksum). These Ethernet packets are forwarded by the Ethernet switch 5 to the Higher transport functions 62 of the central module 6, which now comprises software for IP routing functions. That is, in this example the routing is performed by the central module. The packets are then forwarded, via the Ethernet switch 5, to the interface module 2. The IP data link layer functions thereof convert the Ethernet encapsulation of the IP packets into another layer 2 encapsulation suitable for the external network, which is e.g. connecting to another base station.
In the example of terminated traffic, the interface module 4 receives IP packets destinated for the radio frequency block. The IP data link layer functions 41 encapsulate the received IP packets into Ethernet frames, similar as in the case of the routed 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. The IP Routing functions convert (e.g., extract) the Ethernet frames into IP packets (or packets of another protocol suitable for the radio frequency block) and forwards them to the transport/baseband interworking function 61 of the central module.
Thus, according to the arrangement shown in
Hence, according to the present embodiment, the transport protocol used for the TB can easily be changed between IP and ATM by changing the software of the lower and higher transport functions. No exchange of hardware is required.
Thus, according to the present embodiment, the 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 which can be handled by the switch 5. The conversion between the Ethernet frames and the outside network protocol (e.g., IP or ATM) is fully handled via software in the lower transport functions 11, 21, 31 and 41. Likewise, the higher transport functions 62 of the central module convert the traffic received via the switch 5 into a protocol suitable for the higher functions of the transport block, for example, and vice versa. Thus, the internal Ethernet structure of the node forms a universal and never changing basis, on which several externally visible network protocols as ATM and IP can be realized just by providing the adequate software.
In the case of an operator-initiated change from Iub/ATM to lub/IP, the operator will load a new software package into the TB, using the normal housekeeping functions of the TB 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 universal node platform by installing the appropriate embedded software in production.
The software update can be performed via the network so that no maintenance on location is required. For this, a specific program loader may be provided which loads the new software into the corresponding interface modules and the central module.
The software might be delivered as a software package containing suitable software binaries for each module type. Using the software management functionality of the node and of the network management system, the software package might be downloaded into the node via the remote management connection. The software management functions of the node might then distribute the contained software binaries to the corresponding modules. Along with the software package, a configuration file containing the required new settings of the node might be downloaded. The download successfully finished, the network management system might activate the new software package. Having received remotely the activation command, the node might then start the new software, e.g. by rebooting with the new binaries. After activation, the node might automatically apply the settings defined in the configuration file. With proper settings in the configuration file, the node (which might have operated as an ATM cross-connect before) might immediately perform its new role (e.g. IP router).
Hence, according to the present embodiment, a mobile operator can change the transport network from ATM to IP with pure software download, without changing hardware. Telecommunications equipment vendors can use exactly the same hardware platform for ATM and IP transport blocks and stand-alone transport nodes. The maintainability is increased, since a bug fix does not require the redesign and replacement of transport protocol-specific integrated circuits, but only a new software release. New features can be easily amended.
According to the first embodiment described above, an architecture was described comprising a central module and additional interface modules. But also an architecture is possible in which all functionality is located in a single module.
In the following, a second embodiment is described according to which a single module transport block 7 shown in
Thus, the transport block according to the second embodiment does not need a switch as according to the first embodiment.
Summarizing, according to the invention an implementation and mechanism (software upgrade) is provided in order to overcome the problem of needed hardware replacement when changing the transport protocol on the Iub interface in the WCDMA RAN from ATM to IP. A flexible base station hardware can support both ATM and IP transport protocols (e.g. by using network processors or FPGAs (Field Programmable Gate Arrays) in the implementation). Whether ATM or IP is used, is only determined by the embedded software of the transport block, and not by any hardware. This allows mobile operators in-field upgrade of the BTS from ATM to IP via remote software change, without the need of very expensive site visits and hardware replacements.
Thus, there are three main applications for the invention described above:
However, it is noted that the invention is not limited on these applications.
The above description and accompanying drawings only illustrate the present invention by way of example. Thus, the embodiment may vary within the scope of the attached claims.
For example, according to the embodiments described above, the network node is a base station. However, the invention is not limited thereon. By contrast, the network node according to the present invention can be any suitable network element or unit in which some transport functions are provided. For example, the network node my comprise standalone ATM cross-connects or switches which are needed at hub sites, for example. Furthermore, the network node may comprise an IP router.
That is, the ATM cross-connects or switches can be transformed into IP routers by remote software change, if the hardware is designed accordingly, as described above.
Moreover, the embodiments described above are directed to radio access networks. However, the present invention is also applicable to all telecommunication or data networks deploying ATM nodes or IP routers.
Further on, this invention is not limited to ATM or IP. By contrast, almost all reasonable transport protocol stacks can be realized with the same hardware platform with the proper software.
This application claims priority of U.S. Provisional Patent Application Ser. No. 60/555,293, filed on Mar. 23, 2004. The subject matter of this earlier filed provisional application is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
60555293 | Mar 2004 | US |