ATIS 1000676-2001 BICC IP Bearer Control Protocol (IPBCP).pdf

《ATIS 1000676-2001 BICC IP Bearer Control Protocol (IPBCP).pdf》由会员分享，可在线阅读，更多相关《ATIS 1000676-2001 BICC IP Bearer Control Protocol (IPBCP).pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000676.2001(R2011) BICC IP Bearer Control Protocol (IPBCP) ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment a

2、nd communications industry. More than 250 companies actively formulate standards in ATIS 18 Committees, covering issues including: IPTV, Service Oriented Networks, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, and Billing and Operational Support. In addition, numerous In

3、cubators, Focus and Exploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major

4、 U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . AMERICAN NATIONAL STANDARD Approval of an American National Standard requires revie

5、w by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected inter

6、ests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their exist

7、ence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circ

8、umstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secr

9、etariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw th

10、is standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer all users of this standard are therefore encouraged to investigate the possibility of applying the most recent

11、 edition of the standards and other references listed below. T1.673-2002, Bearer Independent Call Control (BICC) Capability Set (CS) 1+.2IETF RFC 791, Internet Protocol (IP v4).3IETF RFC 1889, RTP A Transport Protocol for Real Time Applications. _ 1A “|” indicates a change from the ITU-T Recommendat

12、ion Q.1970. Strictly editorial changes are not shown. 2This document is available from the Alliance for Telecommunications Industry Solutions, 1200 G Street N.W., Suite 500, Washington, DC 20005. 3This document is available from the Internet Engineering Task Force (IETF). 2 IETF RFC 2327, SDP: Sessi

13、on Description Protocol. IETF RFC 2460, Internet Protocol (IP v6). IETF RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. ITU-T Recommendation Q.1970, BICC IP Bearer Control Protocol.43 Terms and Definitions For the purpose of this Standard, the definitions of T1.673-2002

14、 apply. In addition, the following definitions apply: 3.1 IP bearer: A bi-directional user plane association between two BIWFs for carrying media stream information across IP networks. An IP bearer is an instance of a Backbone Network Connection (BNC) type defined in T1.673-2002. 3.2 Initiating Bear

15、er Inter-Working Function (I-BIWF): A BIWF initiating the establishment of an IP bearer. 3.3 Receiving Bearer Inter-Working Function (R-BIWF): A BIWF receiving an IP bearer establishment request. 4 Abbreviations This Standard uses the following abbreviations: BCF Bearer Control Function BICC Bearer

16、Independent Call Control BIWF Bearer Inter-Working Function BNC Backbone Network Connection CSF Call Service Function DTMF Dual Tone Multi-Frequency IP Internet Protocol IPBCP IP Bearer Control Protocol I-BIWF Initiating BIWF RTP Real time Transport Protocol SDP Session Description Protocol R-BIWF R

17、eceiving BIWF UDP User Datagram Protocol _ 4This document is available from the International Telecommunications Union. 3 5 Overview The purpose of IPBCP is to exchange information between two BIWFs necessary to establish or modify IP bearers. IPBCP makes use of the SDP defined in RFC 2327 to encode

18、 the information that is exchanged. SDP descriptors used for IPBCP also contain IPBCP-specific SDP attributes. 6 IPBCP Messages IPBCP uses messages to convey information between peer BIWFs. IPBCP defines four messages: 1) The Request message is sent by a BIWF to initiate an IP bearer establishment o

19、r modification request. The BIWF that initiates an IP bearer establishment request is denoted as the I-BIWF. 2) The Accepted message is sent by the BIWF that receives an IP bearer establishment or modification message if it accepts the request. The BIWF that receives an IP bearer establishment reque

20、st is denoted as the R-BIWF. 3) The Confused message is sent by a BIWF in response to an IP bearer establishment or modification request if it cannot process the received Request message. 4) The Rejected message is sent by a BIWF in response to an IP bearer establishment or modification request if i

21、t rejects the request. Either an I-BIWF or an R-BIWF may initiate an IP bearer modification request. 6.1 IPBCP Message Contents Each IPBCP message consists of the following SDP fields: Session and time description fields: 1. Protocol version (v) 2. Origin (o) 3. Session name (s) 4. Connection data (

22、c) 5. Session attribute (a) The session attribute identifies IPBCP version and message type. 6. Time (t) Media description fields: 1. Media Announcement (m) 2. Media attributes (a) Additional attributes for the support of RTP dynamic payload types, DTMF, other tones and signals and packetization tim

23、e. NOTE 1 - Some of the fields and sub-fields are included because they are mandatory and required by SDP but not relevant to IPBCP environment. 4 NOTE 2 -The above fields must be present in the order as specified in RFC 2327. NOTE 3 - Other SDP fields may be included in an IPBCP message, however th

24、ey are not required by this Standard and may be discarded by the receiver if they are not understood. 6.2 IPBCP Message Fields The following list describes SDP fields as used by IPBCP. 1-Protocol version: v=0 SDP version 0 is used 2-Origin o= is set to “-“; not used by IPBCP. is set to “0“; not used

25、 by IPBCP. see RFC 2327. type is “IN”; for Internet. is “IP4” or “IP6”. is the IP address assigned to the BIWF sending an IPBCP message. The receiver shall ignore the content of the address sub-field. IPBCP has no requirements on the content of the origin field. NOTE - The above sub-fields are requi

26、red to respect SDP rules. 3-Session name s= an arbitrary string identifying the session. IPBCP has no requirements on the contents of the session name field. 4-Connection data c= is “IN”. is “IP4” or “IP6”. is a unicast address. Only unicast streams are supported (e.g., point to-point) in this versi

27、on of IPBCP. For the details see RFC 2327. 5-Time 5 t= The sender shall set and according to SDP rules. The receiver shall ignore the contents of this field. Values (0,0) are allowed. IPBCP has no requirements on the contents of the Time field. 6-Session attribute SDP session attribute “ipbcp” provi

28、des the means to identify the IPBCP version and to distinguish between Request, Accepted, Confused, and Rejected messages. a=ipbcp: = 1; this Standard defines IPBCP version 1. = (“Request” / ”Accepted” / ”Confused” / “ Rejected”) NOTE - Since IPBCP only supports the establishment of bidirectional be

29、arers, these bearers are by default of type send and receive. Therefore the SDP attribute a=sendrecv does not need to be signaled. 7-Media announcement m= The “fmt list” is limited to only one payload type. For further details see RFC 2327. 8-Media attributes To specify capabilities for DTMF digits

30、and other tones and signals, the format of the media attribute is as follows: a=fmtp: For further details see RFC 2833. To specify RTP dynamic payload types, the formats of the media attribute are: a=rtpmap:/ For further details see RFC 2327. To specify the packetization time, the format of the medi

31、a attribute is: a=ptime: where is the media packetization time in milliseconds. For further details about the use of the ptime attribute with RTP, see RFC 2327. 7 Transport of IPBCP Messages IPBCP assumes a reliable, sequenced, point-to-point signaling transport service between peer BIWFs. 6 8 Proce

32、dures 8.1 Successful IP Bearer Establishment 8.1.1 Initiating BIWF When an I-BIWF receives a request from a control entity to establish an IP bearer, it shall send a Request message to the R-BIWF and start timer T1. The Request message must include one Media Announcement (“m” field). The “c” field s

33、hall include an interface address within the I-BIWF, which specifies the intended source and sink of the media stream at the I-BIWF. The request message may also contain optional media attribute fields such as tone and signal capabilities and packetization time. Upon reception of an Accepted message

34、 from the R-BIWF, the I-BIWF shall stop timer T1 and shall check the Accepted message. Successful IP bearer establishment requires that: The received Media Announcement is the same as the one included in the Request message, except for the port sub-field which can be different. Except for the ptime

35、and tone and signal capabilities, the media attribute fields must be the same as the ones included in the Request message. The optional ptime, tone, and signal capabilities, if included in the Accepted message, are acceptable values. If the I-BIWF accepts the contents of the Accepted message, the IP

36、 bearer is successfully established at both BIWFs, and the control entity that initiated the establishment request shall be notified. 8.1.2 Receiving BIWF Upon reception of a Request message from the I-BIWF, the R-BIWF examines the information in the Request message, and if it is acceptable, shall r

37、eply to the I-BIWF with an Accepted message. The Accepted message must include one SDP “m” field. The “c” field shall include an interface address within the R-BIWF, which will be the source and sink of the media stream at the R-BIWF. Except for the port sub-field, the “m” field must be identical to

38、 the one received in the Request message. The Accepted message may also contain optional media attribute fields such as tone and signal capabilities and packetization time. Returning an Accepted message to the I-BIWF implies that the IP bearer has been established at the R-BIWF. 8.2 Successful IP Be

39、arer modification Once an IP bearer is established, it can be modified at the request of a control entity at the I-BIWF or the R-BIWF. Only the “fmt list” of the media announcement field and the media attributes being used for an IP bearer can be modified. 8.2.1 BIWF Initiating IP Bearer Modificatio

40、n The BIWF initiating the modification request sends a Request message to its peer BIWF and starts timer T2. The Request message must include a single Media Announcement (“m” field) and the media attributes to be changed. 7 Upon reception of an Accepted message from the peer BIWF, the BIWF that init

41、iated the IP bearer modification request stops timer T2 and checks the Accepted message. Successful IP bearer modification requires that: The received Media Announcement is the same as the one included in the Request message, except for the port sub-field which can be different. Except for the ptime

42、 and tone and signal capabilities, the media attribute fields must be the same as the ones included in the Request message. The optional ptime, tone, and signal capabilities, if included in the Accepted message, are acceptable values. If the BIWF accepts the contents of the Accepted message, the IP

43、bearer is successfully modified at both BIWFs and the control entity that initiated the modification request shall be notified. 8.2.2 BIWF Receiving IP Bearer Modification Upon reception of a Request message that applies to an existing IP bearer, the BIWF checks the Request message and, if acceptabl

44、e, replies with an Accepted message. The Accepted message must contain a single Media Announcement (“m” field). Except for the “port” sub-field, this Media Announcement must be identical to the one received in the Request message. The ptime, tone and signal capabilities may be different from the val

45、ues received in the Request message. Returning an Accepted message implies that the IP bearer has been successfully modified at the BIWF. 8.3 IP Bearer Release There are no IPBCP messages exchanged between the two BIWFs to release an IP bearer. NOTE - When IPBCP is used in BICC environment, IP beare

46、r release is triggered by CSF. 8.4 Compatibility Procedures IPBCP uses a basic compatibility mechanism based on version numbers, included in each IPBCP message. Each future revision of this Standard shall support the version sub-field. Peer BIWFs must use the same version of IPBCP in all messages re

47、lated to the same IP bearer, except for the Confused message, when the R-BIWF does not support IPBCP version of the I-BIWF. An R-BIWF receiving an IPBCP message with an unsupported version shall return a Confused message with the version it supports. An I-BIWF receiving a Confused message shall exam

48、ine the IPBCP version number indicated in the message. If the version number indicated in the Confused message is supported by the I-BIWF, it may re-initiate an IP bearer establishment request using this version number. Otherwise, the I-BIWF notifies the control entity that initiated IP bearer estab

49、lishment request. 8 8.5 Procedures for Exceptional Conditions 8.5.1 IP Bearer Establishment 8.5.1.1 Initiating BIWF Upon reception of a Rejected message or an incorrect or erroneous Accepted message from the R-BIWF, the I-BIWF shall stop timer T1, release the resources allocated to the IP bearer and notify the control entity that the IP bearer establishment has failed. 8.5.1.2 Receiving BIWF Upon reception of a Request message from the I-BIWF, the R-BIWF shall check the contents of the message. If they are incorrect or the Media Announcemen