2B Channel Transfer (TBCT) is a Central Office (CO) feature found in Lucent's Class 5E and Nortel's DMS switches. What is TBCT? It's the glue that allows your phone system to transfer an inbound caller to your home, cell phone or other number without tying up two trunks (trunk to trunk transfer) and uses the CO features that are the same as those found in Centrex. Call it mobility.
2B Channel Transfer (TBCT) is a Central Office (CO) feature found in Lucent's Class 5E and Nortel's DMS switches.
What is TBCT?
It's the glue that allows your phone system to transfer an inbound caller to your home, cell phone or other number without tying up two trunks (trunk to trunk transfer) and uses the CO features that are the same as those found in Centrex. Call it mobility.The problems are:
* Carriers don't always know they have it or how to properly configure TBCT * Not all telephone systems support TBCT * Many customers don't know about TBCT * Sales people may not understand TBCT
TBCT is glue that could be very useful, provided of course your telephone system supports the feature and you can convince your carrier to provision it. TBCT is normally supported over PRIs.
The benefits of TBCT are:
* PRI channels are freed up once the caller is transferred (traffic management) * Less time * Audio quality is only affected by the cellular carrier (no more trunk-to-trunk transfers) * The call is supervised (no more hung trunks or busy out conditions set by the Telco on hung DID calls)
I would think that TBCT could contribute to unifying communications by providing a means to get a caller out of the telephone system and to the user on the road, at home or in some other location.
The problem is getting the communicators to communicate. TBCT including PRI stands to be obsolete in another year or two, according to one manufacturer I spoke with. The same was said of analog DID trunks in the mid-1990's. Yet, here we are today, still with a need to glue office calls to cell phones and analog DID trunks are alive and well, as is T1 and PRI.
Why is TBCT important?
It doesn't matter whether or not you have an IP-PBX, TDM box, hybrid or hosted solution. What you must have is glue. TBCT is an ISDN PRI feature and regardless of what happens to ISDN, TBCT is the base level of signaling everyone needs. Getting calls from enterprise desk phones to mobile phones should not require using two trunks or two channels--both methods are bonding two lines together, wasting resources. And when, not if, the cellular carriers get off their dairy airs and provide IP trunking and signaling, TBCT is the same kind of glue that will need to be present in the interface between office and cell phone. Advanced signaling, which really is an old method from AT&T, is look-ahead-routing. Instead of looking to see if an agent or call center is busy, new signaling needs to look ahead to determine if the user's desk phone is in the forwarded mode to a cell number, and then these calls never hit the span (access) to the customer premise for longer periods of processing. Beyond the signaling, there are other opportunities for the cellular carriers, and more reasons to enhance and bundle cell services and access methods to and from customer premises.
Now considering what I said, if the carriers want to capture both landline and mobile traffic; this bundled traffic will cost them less and earn greater profitability. IP benefits will elude enterprise users until both the landline and cellular carriers get it into their heads that there are benefits to providing more than just airtime for premium prices and ridiculous calling plans that only benefit the carriers.
The other item I'm not ignoring is access. Of course this idea opens up a can of worms. What if the enterprise customer wants one vendor for landlines and the other for cellular traffic? Why should it matter?
All credit for the documentation below goes to the great board over at Sundance Communications. When it comes down to the wire, getting the call to the right place on the right medium in an efficient and effective manner is what's required. Mobility still requires glue.
5ESS Notes:
23.5.6 Feature Operation
Initially there are at least two calls over the PRI between end-users and the controller. Each call uses a B-channel on the PRI. To be eligible for TBCT transfer, at least one of the calls must be in an answered state; it may have been initiated by the end-user or by the controller. The other call may be in an answered state, or, if initiated by the controller, it may be in a ringing state.
If the controller determines that two of the calls are to be transferred to each other, the controller sends a request for two B-channel transfer to the 5ESS switch. When the 5ESS switch receives the request from the controller, it checks the validity of the message containing the request, the states of the calls to be transferred, the compatibility of the bearer capabilities of the calls, whether the PRI groups associated with the B-channels in the request are provisioned for the feature, whether the PRI groups are members of the same PRI serving group (see below for explanation of PRI serving group), whether interactions with other services or features should prohibit execution of the transfer, and other criteria. If any of the checks fail, an error message is sent to the controller, and the calls remain connected to the controller. If the checks pass, the 5ESS switch performs the TBCT transfer operations. The two users' calls are then connected together at the switch, and the two B-channels, which were previously occupied on the PRI by the users' calls to the controller, are released. After the transfer, the two B-channels are available for new calls to the controller.
The multiple interface capability allows transfers between B-channels that are on different PRI groups, that is, B-channels that are associated with different D-channels. A PRI serving group is introduced with this feature. A PRI serving group consists of members, each of which is a PRI group. All members of a PRI serving group must be on the same SM (Service Module).
This feature also provides two counters that are available to control requests and usage of the feature on a per PRI group basis. If the two B-channels are from different PRI groups, one counter is incremented -- that of the PRI group with the B-channel that requests the transfer. One counter records the number of TBCT requests per 10-second interval. If the number of TBCT requests reaches a provisionable limit within the time interval, all additional requests are denied in the current time interval. The second counter records the number of active transfers, that is, the number of transferred calls that are currently active. If the number of active transfers reaches a provisionable limit, all subsequent TBCT requests are denied. (It is also possible for the number of active transfers to exceed the limit, for example if the limit is lowered while there are active transfers on the interface.) When a sufficient number of transferred calls are cleared, such that the number of active transfers no longer equals or exceeds the limit, new TBCT requests will be allowed. An audit is provided to ensure the integrity of the active transfers counter.
Traffic measurements are provided to record feature usage on a requesting PRI group basis. The number of valid TBCT requests, the number of successful TBCT transfers, the number of overflows of the active transfers counter, and the number of overflows of the transfer requests per current interval counter are measured.
As an enhancement to Feature 99-5E-3261 (Two B-Channel Transfer [TBCT] on PRI), the TBCT Notification to Controller feature, 99-5E-7268, sends notification to the controller when the transferred call is cleared. A non-call associated NOTIFY message is used. When the Notification to Controller feature is active, the switch assigns a Call Tag to the TBCT call at the time of the transfer. This Call Tag is unique at the PRI interface serving the controller. If the multiple PRI option is subscribed, the Call Tag is unique across the PRI serving group. The switch retains an association between the Call Tag, the transferred call, and the controller's interface throughout the duration of the transferred call.
The base TBCT feature, 99-5E-3621, passed the number of active and available transfers to the controller in the DISCONNECT message at the time of the transfer. When the TBCT NTC feature, 99-5E-7268, is active on the PRI group, the DISCONNECT message will also include the Call Tag assigned to the transferred call. The switch sends a NOTIFY message to the controller, when the TBCT transferred call clears. The NOTIFY message contains two notifications. One notification contains the Call Tag value to alert the controller that the TBCT call associated with the Call Tag has cleared and a second notification provides the updated number of active and available transfers on that PRI group. The Notification to Controller feature is provided on a per PRI GROUP basis.
NOTE: Notification to Controller can be subscribed only if TBCT is active.
DMS-100 Family Notes:
Translations Guide Volume 10 of 25 Data, ISDN, and Internet Services Part 3 of 3
7-20 Datafilling NI0 NI-2 PRI 7-20 7-20 PRI two B-channel transfer
Ordering codes
Functional group ordering code: NI000015 Functionality ordering code: NI000018
Release applicability
NA009 and up for Notification to controller and TBCT across D-channels. NA008 and up for base TBCT feature.
Prerequisites
PRI two B-channel transfer has no prerequisites.
Description
PRI two B-channel transfer (TBCT) capability on National ISDN 2 (NI-2) primary rate interface (PRI) trunks gives customer premises equipment (CPE) more efficient use of trunk connections for calling traffic. With a private branch exchange (PBX), or a network of PBXs, multiple call forward and transfers are typical. When a forwarded or transferred call is set up using two B-channels in a PRI trunk, the original channels can be released and made available for future calls. The controller can be an intelligent peripheral (IP), a private branch exchange (PBX), or other customer premise equipment (CPE).
The CPE requests TBCT by sending a Facility message with a TBCT invoke component in it to the Service Switching Point (SSP). If the SSP determines that all validation criteria pass (for example, bearer capabilities and feature interactions), then the SSP performs TBCT. The SSP responds with a facility message that acknowledges the TBCT request. All billing, including AMA billing, proceeds as if the TBCT transfer never occurred.
Note: For per trunk signaling (PTS) trunks, the system denies TBCT during the alerting phase. PTS trunks outpulse digits to the far end. TBCT disrupts digit outpulsing, and the call cannot be completed.
Operation
PRI TBCT provides the capability to connect two independent calls (the calls may be on the same or different NI-2 interfaces between the controller and the DMS) at the request of a controller. The system sends this request to the SSP in the form of a Q.931 FACILITY message containing an invoke component coded with a TBCT operation identifier.
Translations table flow
The PRI two B-channel transfer tables are described in the following list:
* Table SVPRIGRP defines Serving PRI Groups. All PRIs that belong to the same Serving PRI Group are viewed as terminating at the same destination. When requesting TBCT across D-channels, (that is, across PRI interfaces), the two PRIs must be in the same Service PRI Group for the request to be accepted. Through table SVPRIGRP, the operating company can create up to 1,022 serving PRI groups. A serving PRI group is identified through the key PGRPID in table SVPRIGRP. This key is referenced in table LTDEF to identify logical terminal identifiers (LTID) that belong to a serving PRI group.
* Table LTDEF defines the service profile of an ISDN logical terminal (LTID). The key to this table is an LTID. An LTID consists of a logical terminal group (LTGRP) from table LTGRP and a logical terminal number (LTNUM) in a range of 1 to 1,022. This table must be datafilled to provision primary rate interface (PRI) and basic rate interface (BRI) services. The type of service requested is distinguished by the LTCLASS field, for example, BRAFS, PRA, and BRAMFT. Based on the type of service, logical terminal specific options can be datafilled against a particular LTID. The PGRPID field in table LTDEF associates the LTID with a Serving PRI Group.
* Table LTDATA (Logical Terminal Data) stores service-related data associated with the logical terminal identifier (LTID [field LTDKEY]), which is the key to this table. Field LTDKEY consists of three parts: the logical terminal group (subfield LTGRP), logical terminal number (subfield LTNUM), and logical terminal data type (subfield DATATYPE). The TBCT option must be datafilled in table LTDATA for the TBCT request to be accepted. In the case of TBCT across D-channels, TBCT must be datafilled on both PRIs involved in the transfer.
* Table BCCOMPAT (Bearer Capability Compatibility) defines the bearer capability (BC) pairs that are compatible with one another. For example, a terminal with a 300-baud modem BC can communicate with a terminal with a 300- to 1200-baud modem BC. TBCT calls are accepted only if the two calls involved in the transfer have compatible bearer capabilities.
