* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download II. bicc overview
Survey
Document related concepts
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Computer network wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Zero-configuration networking wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Internet protocol suite wikipedia , lookup
Airborne Networking wikipedia , lookup
Routing in delay-tolerant networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
Network Resource Reservation in the Next Generation Networks using BICC as a Call Control Protocol Lovre Hribar, Damir Buric, Alen Bulic Ericsson Nikola Tesla R&D Center, Split, Croatia [email protected], [email protected], [email protected], Abstract—Architecture of the next generation telecommunication network is based on the separation of functionality into independent layers: control layer, a connectivity layer and an application layer. BICC and other Call Control Protocols share the resources in the connectivity layer. The connectivity layer handles the transport and manipulation of user and control data and comprises transport backbone elements and Media Gateways. Media Gateways have been introduced to provide bearer control function and media mapping/switching functions. Resource reservation for Bearer Independent Call Control protocol has most important role in the call setup. The paper gives a detailed overview of bearer set-up procedures in ATM and IP networks based on BICC ITU-T recommendations. technology and signaling transport technology used. It is an extension of Integrated Services Digital Network User Part (ISUP) protocol and therefore provides a full transparency of the existing telephony functionality. The first standardized version of BICC protocol was Capabilities Set 1 (CS1) but only BICC Capabilities Set 2 (CS2) version gives a true separation of control and bearer layer and introduction of IP bearer [5]. The physical separation of the Call Control and Bearer Control allows physically separate Call Mediation Node (CMN) and BIWF. Inherent in this separation is the possibility for BICC CS2 to support the BIWF selection, allowing a many-to-many relationship between call control servers and BIWFs. I. INTRODUCTION When two Media Gateways (MGW) need to set up an communication path over backbone using Asynchronous Transfer Mode (ATM) or Internet Protocol (IP) as a technology Fig. 1, they need to obtain and exchange information about the Bearer Interworking Function Address (BIWF), Backbone Network Connection Identifier (BNC-id), IP addresses, port numbers, codecs that will be used for the speech compression, media streams, etc. BICC using different mechanism for this purpose depending on the transport technology used in the call, but the problems obtaining necessary information and establishing communication path between two MGWs are the similar for the both transport technology. BICC protocol has its own place in the next generation network as a call control protocol and there is a possibility for interwork with other call control protocols in such network [4]. BICC is the call control protocol chosen for the 3rd Generation Partnership Project Circuit Switched domain (3GPP CS) Release 4. This paper gives an overview of the capabilities for the resource network reservation in the connectivity layer for the MGWs terminations Fig. 1 in BICC protocol and tries to explain the conceptual and architectural differences between different transport technologies used in the call scenario. Signalling Transport Network II. BICC OVERVIEW A. Network Architecture using BICC BICC protocol provides the signaling functions required supporting narrowband Integrated Services Digital Network (ISDN) services independent of the bearer LE/TE ISN-A CCF BIWF BIWFBCF BCF CMN CCF ISN-B Call Control Signalling Bearer Control Signalling LE/TE CCF BIWF BIWFBCF BCF BNC-ID Backbone Network Conection Network Bearer Conection (end-to-end) Figure 1. Network Functional Model BICC is used as a protocol between Call Service Functions (CSFs) within different nodes as originating/destination Service Nodes (SNs) (ISNs interworking with an access signaling system), intermediate national/international SNs (TSNs), incoming/outgoing national/international gateway SNs (GSNs) and Call Mediation Nodes (CMN). CMNs are introduced for call routing purposes [6]. They do not have bearer control function. B. BICC using ATM as a transport technology The first version of BICC, BICC CS1 is used in the ATM based network and it is standardized through ITU-T Q.1901 specification [9]. The main body of Q.1901 specification defines the protocol at Transit Serving Nodes and Gateway Serving Nodes. The scope is shown in Figure 2. Serving Node (SN) Call Control Signalling (BICC Protocol) Call Service Function (CCF) Call Control Signalling (BICC Protocol) depends as well on outgoing CSF route characteristics and originating BIWF. The choice between Forward or Backward set-up, respectively, is made by the originating BCF and is indicated in the initial response from the originating BCF. Also in both scenarios there is a possibility for the notification for successfully established bearer. C. BICC using IP as a transport technology Bearer Control Signalling Bearer Control Function (BCF) Bearer Control Signalling Bearer Figure 2. Scope of BICC CS1 This specification describes the adaptation of the narrow-band ISDN User Part (ISUP) for the support of narrow-band ISDN services independent of the bearer technology and signalling message transport technology used. Between Serving Nodes the control of bearers is provided by other protocols – not specified by the specification. Three types of Serving Node (SN) are defined: • Interface Serving Node (ISN) – this type of node provides an interface to circuit switched networks. • Transit Serving Node (TSN) – this type of node provides transit functionality, for call and bearer, within one network using the BICC protocol. • Gateway Serving Node (GSN) – this type of node provides inter-network gateway functionality, for call and bearer, using the BICC protocol. In defining the procedures for BICC at an Interface Serving Node the specification also defines how BICC interworks with other protocols. But the true separation of the Call Control and Bearer Control was introduction of IP as a transport technology, BICC CS2 and it is standardized in ITU-T Q.1902 specification [11], [12], [13]. These specifications provide a functional description of the BICC protocol. Describes the elements of signalling information used by the BICC protocol and the ISDN user part and their functions. Also, specifies the formats and codes of the BICC protocol for the support of narrowband ISDN services independent of the bearer technology and signalling message transport technology used. It also specifies ISDN user part messages and parameters required to support basic bearer services and supplementary services according to ITU-T Q.761. Where a message, a parameter, a parameter field or a parameter field value is not supported by one of the two protocols or they interpret a code point differently, it is also indicated. Finally, describes Capability Set 2 (CS2) of BICC basic call procedures for the support of narrow-band ISDN services independent of the bearer technology and signalling message transport technology used. Depending whether BIWF has been selected prior to outgoing BICC set-up or after there are two different ways of bearer connection set-up: Forward and Backward. It The second standardized version of BICC protocol was BICC CS2 version that gives a true and fully separation of control and bearer layer with introduction of IP as a transport technology [7]. To support IP as a bearer the BICC along with Call Bearer Control (CBC) protocol [10] provides a mechanism for the transport of Bearer Control Protocol information between BIWFs. The mechanism provides a reliable, sequenced transport on a per backbone network connection basis when there is no requirement for intermediate BCF-Rs between the BCFNs to process the tunneled information. The mechanism used in BICC is so called Tunneling mechanism and is defined in the Internet Protocol Bearer Control Protocol (IPBCP) protocol [8]. When IPBCP protocol information has to be passed from one MGW to another, it is tunneled from the MGW via the Bearer Control Tunneling Protocol (BCTP) using Call and Bearer Control extensions to the call control server, then from the call control server to the target call control server via the BICC protocol in the Application Transport Mechanism (APM) message and finally from the target call control server to the target MGW via the BCTP protocol over CBC Fig. 3. Call Control = BICC CSF Signaling transport CBC CSF CBC Bearer Control = Q.IPBC BIWF BIWF Signaling transport Figure 3. Tunneling mechanism The Bearer Interworking Function at the originating SN makes the decision on use of the Bearer Control Tunneling mechanism on a per call basis. The CSF shall inform the BIWF of the possibility of using the Bearer Control Tunneling Mechanism and the BIWF shall respond with an indication of whether the Tunnel should be set up or not. Bearer Control tunneling shall be used for a call if the BICC-data primitive associated with the IAM or the first backward APM message includes the Bearer Control Tunneling information element set to “tunneling to be used”. The absence of the Bearer Control Tunneling information element in the IAM or in the first backward APM (if “tunneling to be used” was not indicated in the IAM) specifies that the bearer control tunneling shall not be used. The CSF does not process the Bearer Control Protocol information transported by tunneling mechanism. The unmodified BCP information is tunneled through the CBC protocol toward the terminating BIWF. The APM message is used for transmission of tunneled information in call control layer. Depending whether BIWF has been selected prior to outgoing BICC set-up or after there are two different ways of bearer connection set-up: Forward and Backward. It depends as well on outgoing CSF route characteristics and originating BIWF. The choice between Fast (Forward or Backward) and Delayed Forward/Backward set-up, respectively, is made by the originating BCF and is indicated in the initial response from the originating BCF. Following the 3GPP standard and its model of core network BICC CS2 defines its own procedures for supporting the codec negotiation, mid-call negotiation and out-of band transport of Dual Tone Multiple Frequency (DTMF) and tone information. The CS2 version also supports the bearer redirection capability as well as procedures for reuse of idle bearers as a network option. (MPLS) bearer transport technology in a label and a nonlabel switching configuration as a candidate for BICC CS3, and provided a set of high-level requirements. One of the main requirement is support of multi-party call configurations allowing a party to add another party to the call and its communication capability type 6 or any other, and release the party that it has added, from the call and its attachment to the bearer(s). It is proposed for bearer re-direction to support establishment of a multi-party service configuration. According to proposals following information should be used at CSF selection of BIWF: The services required by the call, The list of BIWFs which can be used to interface the peer SN, inter-working with Switched Circuit Networks, Network Interconnect Scenarios minimizing the number of BIWFs in the connection At the succeeding SN, the Bearer Control Unit Identifier (BCU-ID) of the BCU selected at the preceding SN. Support of multi-media and related services. D. BICC Capabilities Set 3 Further development of BICC is proposed to be undertaken, and not to be limited to the existing narrowband ISDN service set. BICC should not compete against other Call Control Protocols, which is regarded as an emerging technology. Interworking would be included as far as existing BICC end terminals could support a particular service. BICC standard work is not finished yet and the following items and contributions are some that are proposed to be in the BICC CS3 scope [14]: The BICC CS3 protocol should support as an optional procedure the transfer of text-based Uniform Resource Locator/Uniform Resource Identifier (URL/URI) naming, complementary to the existing digit-based (E.164) naming. The transfer of text-based naming is restricted to the called party for identification purposes only, not for routing purposes. Service platform including ENUM functionality is supposed to map the E.164 telephone number into a SIP-URL. Reverse ENUM functionality supposes the reverse mapping. It is supposed for BICC to fully support the advanced CMN call control procedures. International Emergency Preference Scheme (IEPS) support [1]. The call control procedures shall support a mechanism of relaying CMN exchange data and/or IN data between the CMN (CSF-G) and the Originating SN using functionality already provided in SS7: A mechanism for relaying recording, exchange, and/or IN data between an Originating SN and a CMN with the same network; call routing Screening functionality at the CMN (by the CSF-G). Support for efficient Uni-cast and Multi-cast Services transported on various transport technologies (e.g. ATM, AAL2, IP, etc.) via communications configuration 6 (i.e. conference services supported by using a server). In addition to already supported bearer technology it is proposed to take Multiple Protocol Label Switching III. NEXT GENERATION NETWORK ARCHITECTURE The telecommunication community is migrating towards a new network architecture based on horizontal layers [2]. The change in the network architecture introduces new logical network nodes and also changes the role of existing nodes in the network. This architecture changes the current vertically specialized network into a horizontal layered architecture Fig. 4. APPLICATION SERVER (BICC) APPLICATION LAYER APPLICATION SERVER (BICC) TELEPHONY SERVER CONTROL LAYER TELEPHONY SERVER CONNECTIVITY SERVER CONNECTIVITY LAYER CONNECTIVITY SERVER Figure 4. Horizontal layered architecture In practice the layering means that different levels in network hierarchy are separated and communicate over well-specified interfaces; thus different applications share resources in the lower level of the network. Ericsson’s solution for the next generation networks adopts the layering principles outlined above [3]. The layered Core Network architecture is derived from the current standards reference model by separating the control plane functions in the SN from their user plane functions, thus turning these nodes into Servers and Media Gateways (Connectivity Servers). IV. connection. IAM conveys Application Transport parameter, which has encapsulated BICC signaling information BIWF address, BNC-id, and to indicate that bearer set-up is in the backward direction Fig. 7. CCF CCF CCF BCF (x) BCF (Y) BCF (Z) IAM BEARER SETUP PROCEDURES IAM (Action = Connect forward) IAM (Action = Connect forward) IAM APM (Action = Connect forward, BNC-ID=z1, BIWF-Address=z) APM (Action = Connect forward, BNC-ID=y1, BIWF-Address=y) A. Bearer Setup procedures in ATM network In the ATM network bearer setup is propagated using separate bearer protocol. BICC protocol is used only for exchanging information about BIWF address and BNCID. Bearer Setup request (BNC-ID=y1, BIWF-Address=y) Bearer Setup request (BNC-ID=z1, BIWF-Address=z) Bearer Setup Connect Bearer Setup Connect APM (Action = Connected) CCF CCF CCF BCF (x) BCF (Y) BCF (Z) APM (Action = Connected) COT COT ACM ACM ACM ACM IAM IAM (Action = Connect forward) ANM ANM ANM ANM IAM (Action = Connect forward) IAM APM (Action = Connect forward, BNC-ID=y1, BIWF-Address=y) Bearer Setup request (BNC-ID=y1, BIWF-Address=y) Bearer Setup Connect APM (Action = Connect forward, BNC-ID=z1, BIWF-Address=z) Figure 6. Forward bearer setup, with notification Bearer Setup request (BNC-ID=z1, BIWF-Address=z) Bearer Setup Connect COT ACM ACM ACM ANM ANM CCF CCF CCF BCF (x) BCF (Y) BCF (Z) COT ACM ANM ANM IAM IAM (Action = Connect backward, BNC-ID=x1, BIWF-Address=x) Bearer Setup request (BNC-ID=x1, BIWF-Address=x) Figure 5. Forward bearer setup, no notification Bearer Setup Connect IAM (Action = Connect backward, BNC-ID=y1, BIWF-Address=y) Bearer Setup Connect COT Two possibilities are defined: "Per-call bearer set-up in forward direction" - in which bearer control is achieved using a separate bearer control protocol, initiated in the forward direction (relative to the call set-up direction). In the case of forward bearer set-up the service node that sends an IAM also initiates the set-up of the bearer connection. IAM conveys Application Transport parameter (ATP), which has encapsulated BICC signaling information that indicates bearer setup is in the forward direction. APM conveys Application Transport parameter, which has encapsulated BICC signaling information, BIWF address, BNC-id, and to indicate either notification of bearer set-up is required Fig. 6 or not Fig. 5. "Per-call bearer set-up in backward direction" - in which bearer control is achieved using a separate bearer control protocol, initiated in the backward direction (relative to the call set-up direction). In the case of backward bearer set-up the service node that receives IAM initiates the set-up of the bearer ACM ANM ACM ANM IAM Bearer Setup request (BNC-ID=y1, BIWF-Address=y) ACM ANM COT ACM ANM Figure 7. Backward bearer setup B. Bearer Setup procedures in IP network The IPBCP protocol is used to set up the bearer tunneled in BICC messages, and sent between the BCFs via BICC signaling means. In this case, there are two variations of bearer setup: "Fast set-up" - in which bearer control information is carried in the IAM and subsequent APM(s) messages. This variation is supported for both the forward and backward bearer set-up cases. In the case of fast forward set-up the service node that sends the IAM also initiates the set-up of the bearer connection. Information concerning the bearer set-up is carried transparently between the BCFs via bearer control tunneling. Initial bearer set-up information is available when the IAM is sent. The following Fig.8 show the case when notification of bearer connects is not required. CCF CCF CCF BCF (x) BCF (Y) BCF (Z) IAM (Action = Connect backward, Tunnel data) IAM IAM (Action = Connect backward, Tunnel data) APM (Tunnel data) APM (Action = Connected) APM (Action = Connected) CCF CCF CCF BCF (x) BCF (Y) BCF (Z) COT IAM IAM (Action = Connect forward, Tunnel data) ANM ANM ANM ANM COT ACM ACM ACM ACM IAM (Action = Connect forward, Tunnel data) IAM APM (Tunnel data) IAM APM (Action = Connect forward without notification, Tunnel data) APM (Action = Connect forward without notification, Tunnel data) Figure 10. Fast backward bearer setup COT COT ACM ACM ACM ACM ANM ANM ANM ANM Figure 8. Fast forward bearer setup, no notification "Delayed set-up" - in which bearer control information is carried in APM messages following the first backward APM. This variation is supported for both the forward and backward bearer set-up cases. In the case of delayed backward set-up the service node that receives the IAM initiates the set-up of the bearer connection Fig.11. Information concerning the bearer set-up is carried transparently between the BCFs via bearer control tunneling. The following Fig.9 show the case when notification of bearer connects is required. CCF CCF CCF BCF (x) BCF (Y) BCF (Z) IAM CCF CCF CCF BCF (x) BCF (Y) BCF (Z) IAM (Action = Connect backward) IAM (Action = Connect backward) IAM IAM IAM (Action = Connect forward, Tunnel data) APM (Action = Connect forward with notification, Tunnel data) IAM (Action = Connect forward, Tunnel data) APM (Tunnel data) APM (Tunnel data) IAM APM (Action = Connect forward with notification, Tunnel data) APM (Tunnel data) APM (Tunnel data) COT APM (Action = Connected) APM (Action = Connected) ACM COT ACM ACM ACM ANM ANM COT ANM ACM ANM ACM ANM COT ACM ANM ACM ANM ANM Figure 11. Delayed backward bearer setup Figure 9. Fast forward bearer setup with notification In the case of fast backward set-up the service node that sends the IAM also initiates the set-up of the bearer connection Fig. 10. Information concerning the bearer set-up is carried transparently between the BCFs via bearer control tunneling. Initial bearer set-up information is available when the IAM is sent. In the fast backward set-up case, notification of bearer connect is required. In the case of delayed forward set-up the service node that sends the IAM also initiates the set-up of the bearer connection. Information concerning the bearer set-up is carried transparently between the BCFs via bearer control tunneling. Initial bearer set-up information is unavailable when the IAM is sent. Bearer control tunneling is applicable to the case when notification of bearer connect is required Fig. 12 or not required Fig. 13. CCF CCF CCF BCF (x) BCF (Y) BCF (Z) IAM IAM (Action = Connect forward) IAM (Action = Connect forward) IAM APM (Action = Connect forward) APM (Action = Connect forward) APM (Tunnel data) APM (Tunnel data) APM (Tunnel data) APM (Tunnel data) COT COT ACM ACM ACM ACM ANM ANM ANM ANM or PLMN and good operational support for large-scale use. Work on BICC protocol is still ongoing and new capabilities are being added. IP transport technology always requires longer call setup times in compare with ATM no matter which type of call set-up scenario is used. This is a consequence of more signaling between servers. The layered architecture is being deployed in thirdgeneration networks. This enhanced architecture, provides an inherent flexibility, which allows operators to build scalable and cost effective multi-services solutions in the new telecom world. The modular nature of MGW means it is possible to create nodes with different configuration, functionality, capacity, cost, and reliability and performance level. MGW represents the base for supporting the multimedia services making the convergence of telecom and data in communications possible. Figure 12. Delayed forward bearer setup, no notification REFERENCES IAM CCF CCF CCF BCF (x) BCF (Y) BCF (Z) [1] [2] IAM (Action = Connect forward) IAM (Action = Connect forward) IAM APM (Action = Connect forward with notification) APM (Tunnel data) APM (Action = Connect forward with notification) [3] APM (Tunnel data) [4] APM (Tunnel data) APM (Connected) APM (Tunnel data) COT ACM ACM ACM ANM ANM [5] APM (Connected) COT ACM [6] ANM ANM [7] Figure 13. Delayed forward bearer setup with notification Measurement results (e.g. call set-up times for ATM and IP bearer) for each bearer set-up procedures described in this paper can be found in [5]. [8] [9] [10] [11] V. CONCLUSION [12] This paper has shown the capabilities for the resource reservation in the next generation networks using BICC as a call control protocol using ATM and IP transport technology. BICC supports the full range of ISDN and supplementary services over packet networks. Its strong points are complete compatibility with the existing PSTN [13] [14] Alen Bulić, Damir Burić, Lovre Hribar, ''Implementation of IEPS in Multi Service Networks and impacts on call control protocols'', 12. International Conference on Software, Telecommunications & Computer Networks, SoftCOM 2004 Denis Duka, Lovre Hribar, Damir Burić, ''Horizontal Layering – an Essential Aspect in Modern networking'', 27. International Conference, MIPRO 2004 Denis Duka, Lovre Hribar, Damir Burić, ''Adopting the Horizontal Layering in the GSM/UMTS Network'', 12. International Conference on Software, Telecommunications & Computer Networks, SoftCOM 2004 Lovre Hribar, Damir Buric, “Usage of BICC and SIP protocol in IP core network”, 11. International Conference on Software, Telecommunications & Computer Networks, SoftCOM 2003 Lovre Hribar, Damir Buric, Denis Duka, “ Comparison between ToATM and ToIP using BICC as Call Control Protocol”, 12. IEEE MELECON 2004 Lovre Hribar, Damir Buric, Denis Duka, “Usage of Call Mediation Node in ATM/IP Core Network”, 27. International Conference, MIPRO 2004 Lovre Hribar, Damir Burić, Denis Duka, ''Migration from ToATM towards ToIP using BICC'', 12. International Conference on Software, Telecommunications & Computer Networks, SoftCOM 2004 BICC IP bearer control protocol, ITU-T Recommendation Q.1970. Bearer independent call control protocol, ITU-T Recommendation Q.1901 Bearer independent call bearer control protocol, ITU-T Recommendation Q.1950 Bearer independent call control protocol (Capability Set 2) and Signaling System No. 7 ISDN User part: General functions of messages and parameters, ITU-T Recommendation Q.1902.2. ITU-T, Q.1902.1 Bearer Independent Call Control protocol (Capability Set 2) Functional Description. ITU-T, Q.1902.4 Bearer Independent Call Control protocol, basic call procedures ITU-T, Technical Report TRQ.BICC.CS3 General signaling requirements for the support of narrowband services over broadband transport technologies, BICC Capability Set 3