(Page 1 of 1 in this chapter) Version

Chapter 5

CX 1000 Switching

5.1 Introduction
5.2 CX 1000 MVIP Switch Models
5.2.1 CX 1000 MVIP Switch Model (MVIP-90)
5.2.2 CX 1000 MVIP Switch Model (MVIP-95)
5.3 Hybrids and Timeslots on the Local Bus
5.4 MVIP Bus Adapter Switching
5.5 FMIC Switching Restrictions
5.5.1 Practical Outcomes of the FMIC Limitation
5.6 CT Bus Clocking
5.7 Conferencing

5.1 Introduction

CX 1000 boards are MVIP-90-compliant boards. They can be connected to the MVIP-90 telephony bus to share data and functionality with other boards connected to the same bus.This chapter describes how to use MVIP switching with CX 1000 boards. This chapter is presented assuming a basic knowledge of time-division-multiplexing architecture using streams and timeslots. For more information about switching and time-division-multiplexing, refer to Getting Started With MVIP Switching.

Switching on CX 1000 boards is implemented by the FMIC chip. Applications can address the MVIP switch using the MVIP-95 or MVIP-90 switch block model (see Section 5.2).

Note: MVIP-95 is a subset of the H.100 bus specification. Thus CX 1000 boards are also interoperable with H.100 bus systems. To connect a CX 1000 board to the H.100 bus, you can use a special adapter available from NMS. For details, see the Getting Started with MVIP Switching manual.

Switching operations for the CX 1000 board can be controlled by the following:
Switch Commands

 Description

CT Access Switching service

 Service providing a set of functions for controlling MVIP switches. May be used for MVIP-90 and MVIP-95 device drivers.
For more information, see the CT Access Developer's Manual.

swish utility

 CT Access utility which controls MVIP switches. May be used for MVIP-90 and MVIP-95 device drivers.
For more information, see the CT Access Developer's Manual.

Note: If CT Access 2.1 or greater is not installed, you must use raw driver commands to configure or query line interface gain. For more information, see Chapter 6. Note: We strongly recommend using the MVIP-95 switch model to develop new applications. The MVIP-95 model provides forward compatibility, and is designed to accommodate further telephony bus evolution. Although CX 1000 boards are MVIP-90 boards, they can be accessed using the MVIP-95 model.

5.2 CX 1000 MVIP Switch Models

This section describes the MVIP-90 and MVIP-95 switch models for the CX 1000.

5.2.1 CX 1000 MVIP Switch Model (MVIP-90)

For CX 1000 boards, the specific use of each stream is as follows:
MVIP-90 Streams/Timeslots

 Use

Streams 0..15 (each stream has timeslots 0..31)

 MVIP bus (8 streams with forward connections and 8 streams with reverse connections).

Streams 16 and 17 (each stream has timeslots 0..31)

 CX 1000 line interfaces. Stream 16 carries voice information and stream 17 carries signaling information.

The line interfaces are accessed via the timeslots 0...23. Each line interface n is assigned timeslot number (n-1). For example, the voice information for the first line interface on the board is carried on Stream:Timeslot 16:0. The signaling information for the second line interface is carried on Stream:Timeslot 17:1.

Stream 18

 Reserved for line interface configuration. Applications should not access timeslots on stream 18.

Stream 19

 Local stream with 0 time slots. It is reserved for future use.

Streams 20..40, each with timeslots 0..31

 Available for conferences. A maximum of 16 conference seats are available in up to 5 conferences. For more information, see Section 5.7.

Figure 19 shows the complete MVIP-90 switch model:

Figure 19. MVIP-90 Switch Model for CX 1000 Boards





5.2.2	 CX 1000 MVIP Switch Model (MVIP-95)





For CX 1000 boards, the specific use of each stream is as follows: 





 MVIP-95 Streams/Timeslots



 Use




 Streams 0..15 (each stream has timeslots 0..31)



 MVIP bus.




 Local streams 0 and 1 (each stream has timeslots 0..31)



 CX 1000 line interfaces. Local streams 0 and 1 carry voice information.


 The line interfaces are accessed via the timeslots 0...23. Each line interface n is assigned timeslot number (n-1). For example, the voice information for the first line interface on the board is carried on 0:0 and 1:0. 




 Local streams 2 and 3 (each stream has timeslots 0..31)



 CX 1000 line interfaces. Timeslots on local streams 2 and 3 carry signaling information associated with the voice information in the same timeslots on streams 0 and 1.


 The line interfaces are accessed via the timeslots 0...23. Each line interface n is assigned timeslot number (n-1). For example, the signaling information for the second line interface is carried on 2:1 and 3:1.




 Local streams 4 and 5



 Reserved for line interface configuration. Applications should not access timeslots on these streams.




 Local streams 6 and 7



 Reserved for future use. 0 time slots.




 Streams 8..49, each with timeslots 0..31



 Available for conferences. A maximum of 16 conference seats are available in up to 5 conferences. For more information, see Section 5.7.
















Figure 20 shows the MVIP-95 switch model:





Figure 20.	 MVIP-95 Switch Model for CX 1000 Boards






5.3	 Hybrids and Timeslots on the Local Bus





On the CX 1000 boards, each line interface is hardwired to a specific timeslot on the local bus. Each line interface supports one port of telephone network connectivity. Figure 21 shows how line interfaces are mapped to timeslots.





Figure 21.	 Timeslots and Line Interfaces on the CX 1000 Board




Each line interface is also permanently connected to pins on the DB-62 connector on the end bracket. See Appendix D to learn how line interfaces map to pins.






5.4	 MVIP Bus Adapter Switching





The MVIP bus adapter allows boards connected to the H.100 bus to access the MVIP bus, and allows MVIP boards to access the first 16 streams of the H.100 bus. When connecting H.100 boards to the adapter, the first 16 H.100 streams must be clocked at 2 MHz, where each stream has 32 timeslots. By default, most H.100 boards come configured for MVIP compatibility mode with the first 16 streams configured for 2 MHz.





Figure 22.	 Bus Adapter Streams




Refer to Section 2.5.2, Connecting to the MVIP-90 Bus for more information.






5.5	 FMIC Switching Restrictions





The MVIP-90 Switching Standard is designed to use full duplex streams. When making a full duplex connection using stream 0, the timeslot on DSo0 is used to receive input, and output is driven onto the same timeslot on DSi0. For example:


MakeConnection ( 0:3 to 16:6 )         /* connects DSo0:3 to local stream 16:6 */
MakeConnection ( 16:6 to 0:3 )         /* connects local stream 16:6 to DSi0:3 */




The FMIC chip was built for implementing MVIP-90 switching. It has a "direction" bit in its connection memory for each timeslot that selects either of the following modes:




The FMIC cannot simultaneously send output to both DSi and DSo on the same timeslot on the same-numbered stream, and also cannot simultaneously receive input from both DSi and DSo on the same timeslot. Note that this restriction exists for MVIP timeslots only: local timeslots have no direction associated with them.



Thus if the following MVIP-90 simplex connection is made:


MakeConnection ( 0:3 to 16:6 )         /* connects DSo0:3 to local stream 16:6 */




...then the FMIC establishes DSo0:3 as an input timeslot, and also establishes DSi0:3 as an output timeslot. Even though there are no switch connections made to DSi0:3, the switch block cannot receive input from DSi0:3 because the direction is currently set to "output" for that timeslot in the FMIC. Thus a connection such as the following would cause an error:


MakeConnection ( 8:3 to 18:6 )        /* connects DSi0:3 to local stream 18:6 */




...since this connection attempts to receive input from DSi0:3. 



Here is the same duplex connection as the one shown above, in MVIP-95 terms:


MakeConnection (mvip:0:3 to local:1:6) /*connects DSo0:3 to loc. str. 1:6 */
MakeConnection (local:0:6 to mvip:1:3) /*connects loc. str. 0:6 to DSi0:3 */




When a connection is made using stream 0 timeslot 3, the direction is set for timeslot 3 on stream 1. Stream 0 corresponds to DSo0, and stream 1 corresponds to DSi0. Thus a connection like the following would cause an error:


MakeConnection (mvip:1:3 to local:5:2) /* connects DSi0:3 to loc. str. 5:2*/




The "direction" bit for a timeslot may not be changed until all connections involving the timeslot have been broken. At that point, the next connection involving that timeslot resets its "direction" bit to a new direction.







5.5.1	 Practical Outcomes of the FMIC Limitation





In most applications, this switching restriction is completely invisible. However, you cannot connect the local resources of a card with an FMIC, such as an AG-T1 or CX 1000, over the MVIP bus. Those connections must be made locally on the FMIC. Local timeslots have no direction associated with them.



For example, with a CX 1000, you cannot connect line interface 0 to line interface 1 over the MVIP bus, as shown here (in MVIP-90 terms):


MakeConnection ( 16:0 to 0:0 duplex ) /* connects line int. 0 to DSo0:0 */
MakeConnection ( 8:0 to 16:1 duplex ) /* connects DSi0:0 to line int. 1 */




...since the first connection sets the direction bit for DSo0:0 to "output," and also sets the bit for DSi0:0 to "input". The second connection attempts to receive input from DSi0:0, which is now illegal. The correct way to connect line interface 0 to line interface 1 would be locally, as shown here:


MVIP 90:  MakeConnection (16:0 to 16:1 duplex)

MVIP 95:  MakeConnection (local:0:0 to local:1:1) duplex




If you are migrating to CX 1000 boards from ATI or ASI boards, the FMIC limitation means that your switching programming must change. This is because all local-to-local connections on ATI or ASI boards must be done over the MVIP bus. 



If a connection is unavailable because the direction bit for the timeslot is set oppositely, the MVIP switching driver returns error code MVIP_NO_PATH.






5.6	 CT Bus Clocking





It is necessary for the programmer to establish the type of clocking that will be needed by the CX 1000 board. The clock can be programmed using a script file initiated by the swish utility or through a CT Access Switching service function. 



The following is a sample swish script  where the CX 1000 will be running as a stand-alone board, or will act as the clock master on an MVIP bus:


loaddriver cx = agcxsw 0
drv.resetswitch cx
drv.configclock cx ref = OSC  




The following sample swish script  is for a CX 1000 which will source its clock from the MVIP bus (i.e. be a clock slave):


loaddriver cx = agcxsw 0
drv.resetswitch cx
drv.configclock cx ref = MVIP  




Setting the clock source can also be accomplished by using the CT Access Switching Service API. The following is a pseudo code sample:


swiOpenSwitch(ctahd, "AGCXSW", 0 , 0  &hd);
swiResetSwitch(hd);
swiConfigBoardClock(hd, &boardclock);




boardclock is an argument which points to the structure containing the clocktype, clocksource and network as members of boardclock.



Other clocking options can also be implemented on the CX 1000 board such as the secondary 8 Khz clock (sec8k) on the MVIP bus. For details, see Getting Started With MVIP Switching.


Note:  When connecting the CX 1000 board in a system with an H.100 bus, an H.100 bus board should always be the master clock.





5.7	 Conferencing





CX 1000 boards support telephone conferences, where two or more parties are connected together in such a way that any party can speak to and/or hear any other party. 



In your application, you can use standard CT Access Switching service commands to establish and disconnect conferences. In addition, you can control various conferencing parameters, such as gain or noise suppression. These parameters can be monitored for a given party, for a conference or for all conferences. You can also get status information at each of these levels.



Conferencing is founded on two resources: conferences and conference seats.




Managing CX 1000 conferencing resources can be likened to managing a convention center (see Figure 23 below). The center has 5 conference rooms. Each conference room has a 32-seat maximum capacity. 



The conference rooms each have tables but not seats. The seats are kept in a pool and allocated to conferences as needed. The building has a pool of 16 seats. As parties arrive, they carry seats to the appropriate conferences. As parties depart, their seats are returned to the pool for later use in another conference.





Figure 23.	 Conferences and Conference Seats




Each conference is a local stream on an MVIP switch, with 32 timeslots. To establish conferences and connect or disconnect parties, you simply make connections between these local streams and standard switch streams.



Each conference seat is a timeslot in a conference stream. Any conference timeslot connected to another timeslot is considered an active seat. The CX 1000 conference chip can handle up to 16 total active seats. Since conference streams have 32 timeslots each, a single conference may host all of these active seats.


Note:  To insure acceptable speech quality, no more than 8 seats should be connected to a single conference.


Each connection may be simplex (one way), duplex (two way), or pattern mode (in which a certain pattern of data is repeated in the timeslot in each frame). Typically, connections are duplex.



For more information on establishing conferences and using conference commands, see the Conferencing Developer's Reference Manual.








 
    (Page 1 of 1 in this chapter)  Version




 




tech_support@nmss.com



Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.