Table Of Contents
Designing the Cisco Imatis Mobile Care Solution
Layer 3 Differentiated Services Code Point (DSCP)
Mapping between Layer 2 CoS and Layer 3 DSCP
IMATIS Mobile Nurse Call Systems
IMATIS Hospital Communication System
Cisco Security Agent (CSA) QoS Marking
Unified Communications Manager
Voice Port Utilization and Planning
High Availability (HA) Considerations
Unified Communications Component
IMATIS Hospital Communication System
Solution Component Interconnections
IP Phone to CUCM/IMATIS Connections
Hospital Equipment to IMATIS Adapters
Voice Gateway to Nurse Call System
Active Directory and Cisco Secure ACS
Designing the Cisco Imatis Mobile Care Solution
Quality of Service
The Cisco Imatis Mobile Care Solution includes a number of different services with varying levels of criticality. Since the solution optimizes the clinical workflow and provides a number of patient services, the overall reliability of the end-to-end solution is critical. This chapter describes the various mechanisms for assuring a high level of service from each of the components of the design. Careful consideration to the end-to-end Quality of Service (QoS) is mandatory for a Cisco Imatis Mobile Care deployment.
For an in-depth design guide on QoS, refer to http://www.cisco.com/go/srnd. This publicly available Web site provides excellent Solution Reference Network Design material.
•
Enterprise QoS Solution Reference Network Design Guide Version 3.3
Quality of Service Primer
This document is not an in-depth guide to QoS, but a quick review may be helpful. QoS provides the services necessary to eliminate packet loss while at the same time minimizing jitter and delay in a converged IP network. It is only effective if implemented end-to-end between each of the systems in the Cisco Imatis Mobile Care solution.
There are three main areas of QoS that must be considered in any Cisco Imatis Mobile Care deployment are:
•
•
•
Typically an IP network is composed of a number of Layer 2 networks (VLANs) which are eventually interconnected using a Layer 3 router providing inter-VLAN routing services, and hence end-to-end connectivity. Marking a packet with a Layer 3 marking does not affect how that packet is handled through a Layer 2 network because the Layer 2 network switching fabric does not inspect Layer 3 header information. Likewise, packets marked at Layer 2 does not affect traffic as it is routed at Layer 3.
Layer 2 802.1Q/p
Frames marked at Layer 2 using Class of Service (CoS) are classified and subject to the queuing policy defined on the switch.
Figure 5-1 Layer 2 802.10p
Within 802.1p, the precedence is a 3 bit field, allowing values between 0 and 7. The various bit patterns and their values are:
•
•
•
•
•
•
•
•
Layer 3 Differentiated Services Code Point (DSCP)
The ability to mark traffic at Layer 3 has existed long before the now more common DSCP mechanism. DSCP utilizes the 1 byte Type of Service (ToS) field and preserves it for backward compatibility to the IP Precedence ToS marking. The first three bits of the ToS field are commonly referred to as the IP Precedence and similar to that of CoS with values from 0 through 7, with 0 being the lowest priority and 7 being the highest. The next 5 bits are the DSCP bit indicators, but DSCP actually uses the ToS bits in the overall marking.
Figure 5-2 DSCP
DSCP uses these 6 bits as shown in Figure 5-3 to indicate the relative service level that should be provided to any traffic so tagged.
Figure 5-3 DSCP Service Levels
Mapping between Layer 2 CoS and Layer 3 DSCP
When a frame is marked with DSCP, for example, and it needs to traverse a series of Layer 2 switches or 802.1Q Trunks, how will it be queued in these Layer 2 devices? To accomplish this, there is a mapping that takes place between the Layer 3 mapping field (TOS) and the Layer 2 CoS fields. It is important to note that this mapping between Layer 3 and Layer 2 is set by default on various vendor hardware. On Cisco devices, this is taken care of for you through a mapping process that can be viewed via the show mls qos maps command. This command shows a number of tables, but for reference the default is shown below.
6509_R1#sh mls qos mapsDscp-cos map: (dscp= d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9-------------------------------------0 : 00 00 00 00 00 00 00 00 01 011 : 01 01 01 01 01 01 02 02 02 022 : 02 02 02 02 03 03 03 03 03 033 : 03 03 04 04 04 04 04 04 04 044 : 05 05 05 05 05 05 05 05 06 065 : 06 06 06 06 06 06 07 07 07 076 : 07 07 07 07The mapping is shown in a more readable format in Figure 5-4. These can be changed however using the mls qos map cos-dscp 10 15 20 25 30 35 40 45 command. In this case, it would map each of the 8 CoS values to the DSCP values shown in the command from lowest CoS priority to highest.
Figure 5-4 Mapping Between Layer 3 Mapping field (TOS) and Layer 2 CoS Fields
Trusting QoS CoS/DSCP
When a packet arrives on an inbound port of a switch, should the switch trust these markings? In the case of a service provider delivering broadband to the home, for example, it may not be wise to trust frames marked with a high priority. Each switch has the ability to either trust CoS, DSCP, or IP Precedence. By default, the switch rewrites the QoS values to 0, effectively nullifying the QoS markings previously marked upstream. Many times this fact is missed during the configuration steps and as such the marked traffic is reclassified to best-effort. To configure the switch to trust the QoS markings received on a port, you must enter the mls qos trust command. This command allows the network administrator to set, on a port-by-port basis, the default trust behavior, allowing DSCP, COS, or IP Precedence to be trusted.
6509-R1(config-if)#mls qos trust ?cos cos keyworddscp dscp keywordextend extend keywordip-precedence ip-precedence keyword<cr>Cisco IOS Voice Gateway QoS
In order to interface to a nurse call system for voice call back, a voice gateway (GW) may be necessary. This device is typically an Integrated Services Router such as Cisco 2800 series or 3800 series, for example, which is configured with FXO, FXS, E&M, T1, or E1 voice interfaces. In some deployments where voice connectivity is required directly to the IMATIS Mobile Nurse Call system, the voice GW physically resides at the access layer in the network, typically on a nursing floor and often co-located in the same wiring closet as the IMATIS Mobile Nurse Call system.
The voice GW uses Cisco IOS to digitize analogue voice signals or protocol translate digitized voice traffic and map it to H.232 RAS traffic. Once this traffic is mapped, the DSCP bits are set to CS3, typically through a policy-map. This policy-map is one example of how to mark the H.323 signaling traffic at the edge switch. Once the policy map is configured, it is applied to the voice GW's outbound interface to police all H.323 RAS traffic to ensure the proper DSCP is set. By default, the RTP (audio) stream being sent by the voice GW is marked Expedite Forwarding (EF) and complies to the recommended Cisco campus QoS policy.
class-map match-all ras_signalingdescription class map for H.323 RAS trafficmatch access-group 100!!policy-map set-qosclass ras_signalingset dscp cs3!!interface GigabitEthernet0/0description To access layer switch in Nursing floor 4 Northip address 172.21.52.101 255.255.255.240duplex autospeed automedia-type rj45no keepaliveservice-policy output set-qosAlert Generating Systems
Alert generating systems for Cisco Imatis Mobile Care are nurse call, ancillary clinical systems, and fire and security systems. Some of the systems utilize the same physical transport mechanisms (RS-232, IP using ESPA, TAP, etc.), but may require additional configuration when deployed within a healthcare environment.
IMATIS Mobile Nurse Call Systems
Many of the nurse call systems available today provide an RS-232 interface to external systems. The protocol from each of these systems varies across vendors and in some cases across models within the same vendor product portfolio. The common protocols are TAP (Telocator Alphanumeric Protocol), used heavily in North America, and ESPA (European Selective Paging Association), which is widely used in Europe. Despite the protocol used, it is critical that the serial data generated by these systems reliably reach the IMATIS Hospital Communication System for processing.
It is highly recommended that the IMATIS servers be located in a data center environment in order to provide a physically secure environment for this critical component. As such, it may not typically be the case that the data center is within the maximum distance allowable for a serial interface operating at 9600 bps. Long-haul modems may provide a solution to the cable length problem, but at the same time introduce multiple single points of failure and are therefore not recommend.
Conversion of RS-232 serial output to TCP/IP provides a mechanism to extend the reach of the serial interface on a nurse call system to a remote data center. In addition, it is possible to mark this TCP/IP traffic with an appropriate QoS value. In the case of Cisco Imatis Mobile Care, Cisco recommends marking the traffic with AF31 (Assured Forwarding, Mission-Critical data). Most 3rd party RS-232 to IP converters are not capable of marking the traffic themselves and therefore require edge marking at the access layer.
Two examples of third-party RS-232 to TCP/IP converters are provided for reference.
•
•
The Digi One SP device generates TCP traffic on TCP port 771. The device communicates with a software applet installed on the IMATIS Hospital Communication System and appears as an external virtual serial port. In the sniffer trace in Figure 5-5, we can see that the traffic generated by the Digi One SP is not marked with any DSCP QoS as indicated with a DSCP value of 0x00 (Best Effort).
Figure 5-5 Sniffer Trace
In order to mark the traffic generated from the Digi One SP, the following configuration at the edge switch is required.
ip access-list extended Digi_One_SP { Classify Data to be marked with Access-List }permit tcp any eq 771 any { Matches any source IP address with TCP 771 as the source port to any destination IP address }!class-map match-all Digi_One_SP_Class_Map {Associate Access-List to the Class Map }match access-group name Digi_One_SP!policy-map Digi_One_SP_Policy_Map {Mark all traffic matching Class Map as DSCP AF31}class Digi_One_SP_Class_Mapset dscp af31!interface FastEthernet1/0/33description Digi-One-SPswitchport access vlan 10spanning-tree portfastservice-policy input Digi_One_SP_Policy_Map {Apply the policy map to the port where the Digi One SP is connected}!After the marking has been applied to the port to which the Digi One SP is connected, we can see that the traffic is now marked accordingly, AF31.
Figure 5-6 Traffic Flow Marked AF31
Likewise, the Precidia iPocket232 generates TCP traffic on TCP port 9999. In order to mark the traffic generated from the Precidia iPocket232, the following configuration at the edge switch is required.
ip access-list extended iPocket232_ACL { Classify Data to be marked with Access-List }permit tcp any eq 9999 any { Matches any source IP address with TCP 771 as the source port to any destination IP address }!class-map match-all iPocket232_Class_Map {Associate Access-List to the Class Map }match access-group name iPocket232_ACL!policy-map iPocket232_Policy_Map {Mark all traffic matching Class Map as DSCP AF31}class iPocket232_Class_Mapset dscp af31!interface FastEthernet1/0/34description iPocket232switchport access vlan 10spanning-tree portfastservice-policy input iPocket232_Policy_Map {Apply the policy map to the port where the iPocket232 is connected}For other devices that convert RS232 transports to TCP/IP, a similar marking configuration should be used to provide the necessary QoS service levels to the mission-critical data. In the event that the IMATIS Mobile Nurse Call system generates IP-based messages, these can be marked at the edge using a similar marking policy as shown above.
Cisco BSTUN Serial Tunneling
It is possible to utilize a pair of Cisco routers to convert from RS232 to IP and back to RS232. Through the use of Block Serial Tunneling (BSTUN), a serial interface on a Cisco router can be configured to encapsulate the serial traffic into IP. The advantages of using this approach is that some Cisco ISR platforms provide a higher level of redundancy features when compared to lower end point devices. Some examples are dual power and the ability for the router to be multihomed to separate switching fabrics.
It may also be possible to leverage the router to service other traffic types. Examples of healthcare-specific legacy protocols still in wide use include serial printers, bisync printers, SNA, LAT, IPX, and DECnet. Since many of these legacy protocols are still found in many healthcare organizations, providing a dual use for a wiring closet based Cisco router can help offset the cost differential to that of point systems.
BSTUN is supported on the following platforms using IOS version 12.4(17):
1701, 1712, 1721, 1751, 1751-V, 1760, 1841, 2610XM-2611XM, 2620XM-2621XM, 2650XM-2651XM, 2691, 2801, 2811, 2821, 2851, 3631, 3640, 3640A, 3660, 3725, 3745, 3825, 3845, 7200, 7301, 7500, AS5350, AS5350XM, AS5400, AS5400HPX, AS5400XM, and CAT-4500-AGM.
The configuration in Figure 5-7 shows systems connected via an end-to-end QoS-enabled IP network.
Figure 5-7 Block Serial Tunneling (BSTUN) With QoS Marking
hostname NursingFloor4N!bstun peer-name 10.1.1.1!bstun protocol-group 1 async-generic!interface loopback0ip address 10.1.1.1 255.255.255.252!interface serial0description To Nurse Call System 4Northphysical-layer asyncencapsulation bstunasp role secondarybstun group 1bstun route all tcp 10.1.1.5!interface FasteEthernet0ip address 1.1.1.1 255.255.255.0!interface FasteEthernet1ip address 2.2.2.2 255.255.255.0!line 1speed 9600databits 8parity nonestopbits 1hostname MiddlewareGW_RS232_Router!bstun peer-name 10.1.1.1!bstun protocol-group 1 async-generic!interface loopback 0ip address 10.1.1.5 255.255.255.252!interface serial0description To NurseFloor 4North Nurse Call Systemphysical-layer asyncencapsulation bstunasp role primarybstun group 1bstun route all tcp 10.1.1.1!interface FastEthernet0ip address 3.3.3.3 255.255.255.0!interface FastEthernet0ip address 4.4.4.4 255.255.255.0!line 1speed 9600parity nonedatabits 8stopbits 1For more information on BSTUN, refer to:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a00801dbe33.shtml
http://cisco.com/univercd/cc/td/doc/product/software/ios112/asp.htm
Clinical Systems
Most if not all clinical systems on the market have the ability to forward transactions in HL7 format to various ancillary systems over an IP network. As such, it is common to utilize an HL7 interface engine to apply business rules to these clinical or financial transactions, replicating and forwarding them to appropriate ancillary system(s). So for example, an ADT (Admit Discharge Transfer) system may in fact populate the database of ancillary systems (lab, radiology, etc.) with the patient name, ID, and other necessary information. Likewise, a lab system would send lab results or notifications of such results to the clinical results reporting system (EMR).
This transfer of information may occur directly between the ancillary systems or as stated previously may utilize the services of a HL7 interface engine. Some examples of such products include CloverLeaf, Egate, and Siemens Openlink.
Applying QoS markings to such systems can be accomplished using a marking technique similar to that outlined above or can optionally can be marked on the server itself using the Cisco Security Agent (CSA). In the event that the clinical system or HL7 is not able to mark the mission-critical data that it generates with DSCP AF31, CSA has the ability to mark the traffic. In order to implement CSA on these systems, there must be careful planning with the hospitals IT security group and the systems manufacturer.
When it is not possible to mark on the server itself, either through the system's controls or the CSA, edge marking similar to our IMATIS Mobile Nurse Call marking approach must be used. Keep in mind that marking traffic must be performed on both sides of the connection. That is, if marked at a port level on the access layer edge switch from say an HL7 interface engine, the responses from the target system, in this case the IMATIS Hospital Communication System, must also be correspondingly marked.
Figure 5-8 Clinical Results Example with QoS Marking
Fire and Security Systems
Many fire and security systems utilize a similar mechanism as IMATIS Mobile Nurse Call systems to communicate externally as to the status of alarms and other events. This mechanism in many cases is a simple RS-232 connection or in some cases a 20mA current loop. In either case, a device that coverts from such physical interface types into IP is strongly recommended, allowing the IMATIS Hospital Communication System to be located within the data center.
Marking the traffic in both directions is again critical and cannot be underestimated. Edge QoS marking at the switch port for the RS-232 to IP side is most likely the best option for third-party RS-232 to IP converters. As directed in the QoS best practices, it is best to perform QoS marking as close to the source of the traffic as possible. In this case, if the RS-232 converter device is not capable, the next location is on the switch port itself. The example below marks TCP traffic for the Precidia iPocket232 protocol converter provided that the default TCP port setting on the device is not changed.
The example below can be used to mark iPocket232 traffic on an access layer switch such as the Cisco 3750G.
ip access-list extended iPocket232_ACL { Classify Data to be marked with Access-List }permit tcp any eq 9999 any { Matches any source IP address with TCP 771 as the source port to any destination IP address }!class-map match-all iPocket232_Class_Map {Associate Access-List to the Class Map }match access-group name iPocket232_ACL!policy-map iPocket232_Policy_Map {Mark all traffic matching Class Map as DSCP AF31}class iPocket232_Class_Mapset dscp af31!interface FastEthernet1/0/34description iPocket232switchport access vlan 10spanning-tree portfastservice-policy input iPocket232_Policy_Map {Apply the policy map to the port where the iPocket232 is connected}For BSTUN configurations, a configuration similar to the one shown below can be used to establish a BSTUN connection between two ISR routers and mark the traffic accordingly. This configuration has not been validated as part of Cisco Imatis Mobile Care, but is documented here only to provide you with an example.
Figure 5-9 Fire and Security Integration with QoS Marking
hostname Bldg17-BSTUN-Router!bstun peer-name 10.10.17.1!bstun protocol-group 1 async-generic!interface loopback0ip address 10.10.17.1 255.255.255.252!interface serial0description To Fire Alarm Building 17physical-layer asyncencapsulation bstunasp role secondarybstun group 1bstun route all tcp 10.1.1.5!interface FasteEthernet0ip address 5.5.5.5 255.255.255.0service-policy output BSTUN_Policy_Map {Apply the policy map to the outgoing port }!interface FasteEthernet1ip address 6.6.6.6 255.255.255.0service-policy output BSTUN_Policy_Map {Apply the policy map to the outgoing port }!ip access-list extended BSTUN_ACLpermit tcp any range 1976 1979 any {BSTUN TCP Ports 1976, 1977, 1978 and 1979}!class-map match-all BSTUN_ALL_Class_Mapmatch access-group name BSTUN_ACL!policy-map BSTUN_Policy_Mapclass BSTUN_ALL_Class_Mapset dscp af31 {Set traffic matching Class-Map & ACL to af31 }!line 1speed 19200parity Evendatabits 7stopbits 1hostname MiddlewareGW_RS232_Router!bstun peer-name 10.1.1.5!bstun protocol-group 1 async-generic!interface loopback 0ip address 10.1.1.5 255.255.255.252!interface serial1description To Fire Alarm Building 17physical-layer asyncencapsulation bstunasp role primarybstun group 1bstun route all tcp 10.10.17.1!ip access-list extended BSTUN_ACLpermit tcp any range 1976 1979 any {BSTUN TCP Ports 1976, 1977, 1978 and 1979}!class-map match-all BSTUN_ALL_Class_Mapmatch access-group name BSTUN_ACL!policy-map BSTUN_Policy_Mapclass BSTUN_ALL_Class_Mapset dscp af31!interface FastEthernet0ip address 3.3.3.3 255.255.255.0service-policy output BSTUN_Policy_Map {Apply the policy map to the outgoing port }!interface FastEthernet0ip address 4.4.4.4 255.255.255.0service-policy output BSTUN_Policy_Map {Apply the policy map to the outgoing port }!line 2speed 19200parity Evendatabits 7stopbits 1IMATIS Hospital Communication System
The IMATIS Hospital Communication System with regard to QoS is critical to the overall reliability and message delivery assurances needed for a clinical system. Again, there are a few approaches for marking the traffic using DSCP AF31 (Mission-Critical Data). As the focal point used to apply business rules and make forwarding decision, it is critical that traffic is marked in both directions for all protocol flows.
Using IMATIS Order Entry Results reporting as an example, typically these data flows are from the external ancillary system to the IMATIS Hospital Communication System and are TCP/IP port specific. Traffic generated by the lab system can be marked through a number of different techniques as previously discussed. It is critical that the TCP acknowledgments and TCP keep alive traffic from the IMATIS Hospital Communication System back to originating ancillary system is also marked AF31. Without the traffic being marked in both directions, the potential exists for the TCP connection between these two systems to become one way in an over-subscribed network, resulting in a TCP connection failure. This is a result of the acknowledgements and keep-alives being dropped as if they are not marked; they are classified as best-effort. While such events are rare, proper marking of this mission-critical data provides a level of reliability needed in the event of a virus or worm outbreak.
Cisco Security Agent (CSA) QoS Marking
Following best practices for QoS marking and traffic classification, marking the traffic before it exits the host is the most desirable method. This eliminates the effects of a host being moved from its properly-configured port to one that is not configured to provide edge QoS marking. Furthermore, providing the ability to secure the host from vulnerability found in the operating system is an added benefit of using CSA.
The Cisco Secure Agent can provide all of the security benefits to the host machine, but also has the ability to set the DSCP marking of traffic based on a policy. Assigning a DSCP marking to a class of traffic is typically performed at a TCP port level. It can however be classified as any type of IP traffic (TCP/UDP or other IP protocol traffic) that is generated by a specific application or executable running on the host machine. This could, for example, prioritize clinical information flows between a specific application on a well-known TCP port, but not prioritize similar TCP traffic based on the same TCP port but generated by a non-clinical application. Once again, during virus outbreaks or misbehaving applications, having the ability to prioritize critical clinical data flows over scavenger traffic is an obvious advantage to the Medical Grade Network design.
Configuration of the Cisco Security Agent is performed through the use of the CSA Management Console. Figure 5-10 highlights the key traffic marking capabilities found within the CSA Management console. Note how the classification being performed can be applied to a specific application on a specific TCP/IP Port (1720 in this case) or can be applied to all applications as shown.
Figure 5-10 Management Center for Cisco Security Agent V5.2
Once the traffic is marked as DSCP AF31, the traffic is policed according to the end-to-end QoS policy which is configured throughout the network.
IMATIS
The Cisco Imatis Mobile Care solution has a number of Windows-based servers that provide the overall IMATIS solution. As discussed previously, in order to achieve a highly-reliable message delivery system suitable for the healthcare industry, the use of QoS marking for all message-based traffic is mandatory. The following list shows traffic types generated for the solution. On the IMATIS servers, running Cisco Security Agent in order to mark the traffic generated is one method. An alternate method is access-layer edge marking through the use of a route map.
•
•
•
•
•
The following configuration marks traffic generated by an IMATIS server. Your implementation and deployment may vary as services and functions may be separated and deployed on different servers. The configuration below is only intended to provide a framework that can be customized for a given implementation strategy.
ip access-list extended Imatis_ACL { Classify Data to be marked with Access-List }permit tcp any eq 80 any { Matches any source IP address with TCP 80 as the source port to any destination IP address }permit tcp any eq 443 any { Matches any source IP address with TCP 443 as the source port to any destination IP address }permit udp any eq 161any { Matches any source IP address with UDP 161 as the source port to any destination IP address }!class-map match-all Imatis_Class_Map {Associate Access-List to the Class Map }match access-group name Imatis_ACL!policy-map Imatis_Policy_Map {Mark all traffic matching Class Map as DSCP AF31}class Imatis_Class_Mapset dscp af31!interface FastEthernet1/0/40description Imatis Serverswitchport access vlan 10spanning-tree portfastservice-policy input Imatis_Policy_Map {Apply the policy map to the port where the Imatis Server is connected}!QoS Summary and Checklist
To design a Cisco Imatis Mobile Care solution that provides an assurance level for message delivery that meets the demands of the healthcare environment, QoS must be designed into the solution from the start. Voice or mission-critical data traffic should be marked as close to the traffic source as possible. If the generating host is capable of marking the traffic, then this feature should be enabled if not enabled by default. If the originating host is not capable of marking the traffic, the use of the Cisco Security Agent is the next best step where appropriate. If this is not possible, then the traffic should be marked at the edge switch.
Once the traffic generated by both the sending and receiving hosts has been marked, the next step is to enable QoS policies on each network component in the end-to-end network, including wired Layer 2/Layer 3 switches as well as the wireless components, namely the Wireless LAN Controller (WLC).
1.
a.
b.
2.
a.
b.
3.
4.
5.
a.
b.
6.
7.
a.
8.
9.
Unified Communications Manager
The Cisco Unified Communications Manager provides a number of services for a typical installation of Cisco Imatis Mobile Care. First, it provides signaling and control to all handsets registered to it. Second, it must interact with the IMATIS servers using a number of different protocols, which include SNMP, AXL, Syslog, and TAPI. Lastly, it can provide XML services to the phone or, at a minimum, provide the end user with a menu of subscribed services which may include the middleware application and in some deployments Extension Mobility. Some of these traffic flows by standard telephony standards are considered critical for voice delivery and are automatically marked by both the handset and Unified Call Manager. Others are not classified as mission-critical and are therefore not marked accordingly. Because of the nature of the message content as it relates to patient care, it is imperative that all traffic types originating from Unified Call Manager which comprise the Cisco Imatis Mobile Care solution be properly marked as mission-critical data (AF31).
Talking a logical approach, we examine each of the different protocols in the solution and reserve the discussion of the unique protocols respectively in each section for the IMATIS servers.
Endpoint devices generate two primary traffic flows for voice traffic that must be QoS marked and by default Unified Call Manager performs the marking. These can be summarized as the signaling channel and the bearer channel.
The signaling channel is responsible for the control of an endpoint, from collecting digits to signaling an inbound or outbound call. There are three types of signaling traffic in Cisco Imatis Mobile Care:
•
•
•
The second is the bearer channel, which carries the audio or video traffic between endpoints. Again, this is automatically marked by both the endpoints and Unified Call Manager. More specifically, the protocol used to carry the packetized voice traffic is Real Time Protocol (RTP). RTP uses UDP and is dynamically assigned a UDP port number in the range of 16384-32767. The port selection is coordinated and communicated by the endpoints using the signaling protocol configured for the specific endpoint device.
The third protocol used is Trivial File Transfer Protocol (TFTP). This protocol (UDP 69) is used to transfer the configuration to the phone during each registration performed with Unified Call Manager. In addition to the configuration file, ring tones are transferred to the phone when instructed to do so by the IMATIS Hospital Communication System. This enables the phone to have dynamic ring tones that can correspond to various levels of message importance. Since the ring tone in some cases may be signal a critical event requiring immediate attention, TFTP must also be marked as mission-critical AF31.
Since Unified Call Manager automatically marks both signaling and bearer traffic, as well as instructs the registered endpoints as to which DSCP classification to use, there is little or no configuration necessary. Validating that the traffic is marked accordingly should be done during the implementation phase of all Cisco Imatis Mobile Care deployments.
In order to mark XML traffic generated by XML applications running on the phone, the DSCP for Phone-based Services field needs to be configured. This field is accessed on Call Manager and by default is valued at 0x00 for DSCP. When a phone boots up and downloads its configuration file from Call Manager, this setting is pushed to the phone. The field can be found in Unified Call Manager under System > Enterprise Parameters and is shown below.
•
Note
•
The DSCP setting for phone configuration protocols is by default valued to CS3 (Call Signaling 3). Since this conforms to Cisco's recommended QoS Policy for IP telephony, no changes are required. It is however recommended that you verify that this field has been configured accordingly.
Note
Figure 5-11 Cisco Unified CM Administration—Enterprise Parameters Configuration
Likewise, the definition of the field found in Unified Call Manager under System > Enterprise Parameters are shown below.
•
Figure 5-12 Cisco Unified CM Administration—Service Parameters Configuration
Voice
Cisco Imatis Mobile Care lets care providers initiate voice calls in response to events sent to their handsets. This capability is exploited in the following IMATIS services:
•
•
•
•
As a vital part of the overall solution, careful planning and adherence to the related design guides is strongly encouraged for successful deployment.
Voice Port Utilization and Planning
It is important to the overall availability of the system from an end users perspective that there are ample voice ports available to handle any voice call back or offnet calling that is being generated by the clinical staff and patient community. Using the typical voice engineering capacity planning based on the Erlang B protocol, it is possible to determine a recommended number of lines/ports that are needed to achieve a desired level of service. An Erlang is the total number of call seconds generated in one hour during the busiest time during a 24 hour period divided by the number of calls in that same hour. If, for example, the busiest hour generates 3976 seconds in 23 calls, the number of Erlangs can be calculated as:
3976/3600 = 1.104 Erlangs
Next we need to utilize the Erlang B formula shown in Figure 5-13.
Figure 5-13 Erlang B Formula
Where:
•
•
•
To quickly determine the number of lines needed, it may be useful to use the Erlang B calculator found at http://www.erlang.com/calculator/erlb/.
As a working example, let us assume that we have a 40 bed floor that generates, during the busiest hour in 24 hours, 80 calls (each patient calls two times in one hour) and each call lasts 60 seconds. This would generate 80 calls * 60 seconds each or 4800 total call seconds. To determine the number of Erlangs this represents, we divide (80 * 60)/3600, which results in 1.333 erlangs. Next, using the Erlang B calculator found at http://www.erlang.com/calculator/erlb/, we enter 1.333 as the Erlang value. Next we need to determine the number of calls that we can tolerate being blocked per 100 calls. We would therefore enter 0.01 into the Erlang B calculator for the number of blocked calls. Since our goal is not to have any blocked calls, instead of using 0.01, representing one blocked call for every 100 calls, we will use a value of 0.001, which represents one blocked call in every 1000 calls—well above our call volume for the busiest hour encountered. The Erlang B calculator, using these values, tells us that for this floor and call load we need seven lines available.
Figure 5-14 Erlang B Calculator
What this does not take into account, however, is a nursing floor that may have 15 on-duty clinicians along with a dynamic number of transient users, such as physicians on rounds, orderlies, transportation, housekeeping, and so on. If these users utilize the same Voice Gateway for outbound calls, additional capacity may be required. If during the planning process these additional users were not considered and only nurse call bed count was taken into consideration, it may be likely that the voice port capacity has been under-provisioned.
In order to fully understand the voice port capacity engineering, its recommended that the Cisco Imatis Mobile Care design and implementation partner consult the IP Telephony/Voice over IP (VoIP) Traffic Analysis white paper available on CCO at: http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800d6b74.shtml
Disconnect Supervision
With digital voice interfaces such as T1/E1 PRI, T1 CAS, or T1/E1 BRI, disconnect supervision is provided through signaling on the D channel, or in the case of Channel Associated Signaling (CAS), via the robbed bit signaling protocol. In most instances, disconnect supervision on these interfaces is not a problem. For analog interfaces such as FXO, FXS, and E&M interface, the process of signaling a disconnect or end-of-call can sometimes be troublesome depending on the mechanism used.
It is therefore recommended to validate that disconnect supervision is being properly handled between the voice gateway and the legacy system. This validation should be performed for each port that is in use and not just for 1 port. It has been found that some versions of firmware running on the legacy line cards found in some PBXs and nurse call systems do not properly implement the disconnect supervision as required. In some deployments, it may be possible that one line card is running an updated firmware revision that provides the correct disconnect supervision, while another card in the same system is running older code. This is why each port needs to be separately validated for proper call disconnect functionality.
Note
This can be corrected by upgrading the version of firmware on the Dukane station to version 4.01 or higher. The problem on older versions of firmware is that the Dukane system does not recognize a Power Denial-based Supervisory Disconnect, which by default lasts for at least 350ms.
GE/Dukane Disconnect Signaling
* DTMF enter "##" all versions (clinician must enter ## before disconnecting the call)* 40-90 second timeout all versions (Port remains in use for 40-90 seconds then automatically resets)* 300 - 500 ms loop drop GE phone port firmware version <= 4.00 (GE/Dukane Recognizes a power denial in this range)* 250 - 1500 ms loop drop GE phone port firmware version >= 4.01 (GE/Dukane Recognizes a power denial in this range)To assist in troubleshooting disconnect supervision problems, it is recommended that the document called "Understanding FXO Disconnect Problem" which can be found on CCO at the following URL be consulted. http://www.cisco.com/en/US/tech/tk652/tk653/tsd_technology_support_troubleshooting_technotes_list.ht
VoWLAN
The Cisco Imatis Mobile Care solution comprises a number of different horizontal technologies such as VoIP and wireless. As such, each of these technologies, as well as other best practices, are not discussed in detail in this guide. Instead, this document provides a high-level overview of design guidance and references the supporting horizontal design guides. Customer and implementation partners are strongly urged to review each of the design guides for best practices in order to design and implement a robust, scalable, and secure solution deployment. The design guides can be found on Cisco's web site at http://www.cisco.com/go/srnd.
Because of the critical nature of the healthcare industry, it is critical that the underlaying and supporting infrastructure for VoWLAN, namely Unified Mobility, is designed and implemented to support the unique demands of VoWLAN within a healthcare enterprise.
Many healthcare environments have sources of RF interference and these sources are not generally limited to the typical microwave oven or 2.4Ghz cordless phones. Other sources can include 2.4Ghz video cameras, bluetooth devices, as well as patient and visitor devices, such as Wi-Fi-enabled PCs and dual-mode phones. Multipath interference, caused by reflected signals as well as co-channel interference from adjacent hospital wings, must also be considered. Figure 5-15 shows an exaggerated incorrect deployment strategy for a 2.4Ghz, but highlights the increased possibility of co-channel interference found in a typical healthcare environment due in part to poor design and building floor plan.
Figure 5-15 Exaggerated Incorrect Deployment Strategy
Due to the rise in consumer devices within the 2.4Ghz ISM band and the limited number of non-overlapping channels, it is recommended to migrate voice traffic as well as critical data-based services into the 5Ghz band. On the 5GHz (802.11a) band, all 23 channels (depending on geographic area) are non-overlapping channels. This results in an increased network capacity, improved scalability, and the ability to deploy with less likelihood of co-channel interference.
It is therefore recommended to migrate all critical data and voice services to the 5Ghz band whenever possible to reduce the likelihood of interference from a number of sources.
QoS Issues
There are a number of QoS-related issues that should be considered during the Cisco Imatis Mobile Care design and implementation phases. First, let us look at how QoS is handled as it relates to VoWLAN. The handsets are configured during the registration process with Call Manager for the QoS settings that are to be used. By default, both the RTP and SCCP/SIP control channels are Layer 3 marked as DSCP EF and CS3, respectively. At Layer 2, the CoS is 3 for call signaling and 5 for voice. For LWAPP-enabled wireless networks, however, the AP is connected directly to an access-layer switch port. The wireless traffic generated by wireless hosts associated to the AP is encapsulated in LWAPP frames and sent to the controller, typically over a Layer 3 network. So trusting the Layer 2 CoS is not necessary at the switch to which the APs are connected. Instead, DSCP should be trusted in LWAPP configurations.
So switch ports to which LWAPP-enabled access points are connected to should trust DSCP and can be configured using the commands shown below. For Layer 3 uplinks from the access layer to the distribution layer, DSCP should also be trusted.
interface GigabitEthernet1/0/1description LWAPP Access Pointauto qos voip trustmls qos trust dscp<SNIP>interface GigabitEthernet1/0/48description L3 uplink to distributionmls qos trust dscpauto qos voip trustno switchport {enables port as an L3 routed port, not an L2 based VLAN access port}ip address 10.6.1.1 255.255.255.252srr-queue bandwidth share 10 10 60 20 {configured as part of auto qos voip trust command}srr-queue bandwidth shape 10 0 0 0 {configured as part of auto qos voip trust command}queue-set 2 {configured as part of auto qos voip trust command}<SNIP>Since the Wireless LAN Controller trunks multiple VLANs and maps these to specific SSIDs, the WLC therefore connects to the network at Layer 2. As such, trusting CoS as opposed to DSCP is necessary and is shown in the configuration below.
interface GigabitEthernet1/0/1description Connection to Wireless LAN Controllerauto qos voip trustmls qos trust cos { Note that due to bug CSCsi78368, the CoS is not being set properly form the WLC. It is therefore necessary to trust DSCP until WLC release 4.2 }<SNIP>7921G QoS Issue
During the validation phase, it was discovered that the 7921G phone, when running firmware 1.0.4, fails to implement the QoS setting directed by Call Manager for XML/CTI services. The workaround is to view the QoS setting on the phone which causes the value to be written to non-volatile memory, where it is used from this point on, even across phone reboots and power cycles. This fix, CSCsk79795, is scheduled to be included in firmware 1.0.5.
To verify if you are experience this problem, a sniffer trace taken of the traffic being generated by the 7921G when executing XML-based services shows that the DSCP value is configured as 0 or best effort. When viewing the QoS settings on the 7921G handset directly, if configured in Call Manager for AF31 (mission critical data), AF31 is displayed as the value to be used for XML/CTI-based traffic. After viewing this setting on the handset, another sniffer trace should show that the XML/CTI traffic is now marked AF31 as required.
Figure 5-16 XML/CTI Traffic is Now Marked AF31
High Availability (HA) Considerations
The goal of a highly-available system is to eliminate and automate as much as possible all aspects of the solution. A signal point of failure anywhere in the system can lead to unscheduled outages as well as possibly sporadic availability. Monitoring of the overall system end-to-end is also a critical component to determine just how available the system is. Since there are a number of different technologies used in the solution, we break down each component part to identify possible HA architectures. For each major grouping of components, we also include suggested monitoring systems and techniques that can be employed in order to validate the availability.
Unified Communications Component
Cisco Infrastructure
The Cisco infrastructure required to deliver the Cisco Imatis Mobile Care solution can be broken down into a number of horizontal technologies which are described in the subsections below. It is beyond the scope of this document to describe in detail the various high availability aspects of each technology used. For an in-depth discussion, it is recommended that the Solution Reference Network Designs and Cisco Validated Designs (CVDs) be referenced. The SRND and CVDs can be downloaded from http://www.cisco.com/go/srnd and http://www.cisco.com/go/cvd respectively.
In summary, the overall availability of Cisco Imatis Mobile Care depends upon the infrastructure on which it is deployed. Items that should be considered in the high availability planning process include:
•
•
•
•
–
–
–
•
–
–
–
•
•
•
•
•
Although only a summary, this lists items that must be considered during the GAP analysis phase.
Network Components
The network components include the Layer 2 and Layer 3 devices that compose the campus network and specifically include access, distribution, and core layers. There are a number of Solution Reference Network Design guides (SRNDs) available. The key documentation that is recommended for Cisco Imatis Mobile Care include:
•
•
•
•
After reviewing these SRNDs, it is recommended that a GAP analysis or readiness check be performed. To help facilitate this step, it may be helpful to engage a third-party Cisco Certified implementation partner for each of the areas where a GAP was identified. In general, and in line with eliminating all single points of failure in the design, the following are mandatory for achieving a highly available network architecture which is capable of delivering between 99.99% and 99.999% availability. These levels of availability represent between 52.33 and 5.35 minutes of downtime per year, a goal that is highly desirable for any network delivering critical services such as those found in Cisco Imatis Mobile Care.
IMATIS Hospital Communication System
The IMATIS system is built around high availability mechanisms provided through Windows and BizTalk. The system can be configured in a redundant manner, where the IMATIS server and Database Server use Windows clustering and the Message Server uses BizTalk group for redundancy. Through this design, there is always a server available to any components that need to communicate with IMATIS, such as Nurse Call Systems, Hospital Information Systems, or CUCM. To these outside components, a IMATIS server is available. Internally, the redundant servers ensure a server is always available to process new requests.
IMATIS Components
IMATIS is comprised of three servers types:
•
•
•
To form a redundant architecture for these servers, the IMATIS server and SQL server use Windows Clustering and the BizTalk server uses BizTalk Groups to create redundancy. The BizTalk server and the IMATIS server have interfaces to CUCM or adapters to hospital equipment. To ensure that the active server is always available to serve any request, these servers should always be accessed through a virtual IP address. Using Windows Clustering or BizTalk Groups, the actual servers are always reachable through the virtual IP address.
Figure 5-17 IMATIS Redundant Server Architecture
Wireless Mobility Components
To address many of the security requirements with wireless mobility technologies as they relate to Cisco Imatis Mobile Care, this is the list of components in the end-to-end solution:
•
•
•
•
High availability for wireless mobility spans a number of different network infrastructure components. It is assumed for this discussion that the existing wired infrastructure has been designed to provide high availability end-to-end.
Access Points
The recommended 20% overlap is not a recommendation that applies to engineering a highly-redundant network. Rather, the 20% overlap rule is an RF engineering recommendation that attempts to provide seamless roaming by providing the wireless client with enough time to select a new access point onto which it can roam. To achieve High Availability, it is recommended to increase this overlap while paying close attention to the potential for co-channel interferance. In order to provide hardware level redundancy for a centralized wireless deployment, the Wireless LAN Controller (WLC) dynamically adjusts the power output of APs adjacent to one that is no longer available. This capability, and the design aspects of achieving a High Availability wireless design, is discussed in the VoWLAN design guide located on Cisco's Web site:
Wireless LAN Controllers
The Wireless LAN Controllers (WLCs) provide configuration and management for the access-points in the wireless network. Much of this management is both automatic and dynamic in nature and as such requires a redundant design if high availability is to be achieved. It is not only necessary that there are redundant WLCs, but in addition the failure of any single WLC must not over subscribe the surviving WLCs.
If we take, for example, a wireless network consisting of the following, with each controller at 50% of its licensed capacity:
•
•
•
In the above example, the failure of the WiSM would result in 75 APs requiring WLC services. The 4402-12 and 4402-50 only have spare capacity to support 31 APs (6 + 25). It is therefore critical that ample WLC resources are available to support any possible WLC failure scanario.
Security for the WLC should include basic appliance security, which prevents unauthorized user access to the administrative and configuration sections of the WLC. After this, configuration of the wireless network takes into account a few items such as VLAN creation, SSID assignment, RADIUS authentication servers, and of course the encryption and authentication mechanisms used for each SSID.
Authentication
The recommended configuration is to use 802.1X authentication. This mandates the use of an external RADIUS server to authenticate end user devices. By using Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST), the entire authentication stream is encrypted end-to-end. This approach provides a high level of security across the wireless network during the authentication process.
On the 7921G, configuration of EAP-FAST is found under Settings > Network Profiles > [Your Profile Name] > WLAN Configuration > Security Mode. Selecting EAP-FAST and configuring a unique userid and password on the device that conforms to strong security standards is all that must be done. This userid/password combination can be a locally-defined userid/password combination that is located on the ACS server directly. Optionally, the userid/password account can exist within the Active Directory domain which ACS can use as an external authentication database to validate userid/password as configured.
Once the userid/password is authenticated by one of the two means described above, a dynamically created WPA key is generated by the ACS server and effectively pushed to the 7921G to encrypt traffic generated by the device. This includes voice, call control, and XML services. To an observer using a wireless sniffer, all traffic generated by the device is encrypted with dynamically changing keys as provided by the TKIP protocol.
Figure 5-18 Traffic Encrypted with Dynamically Changing Key
Another item that must be completed in order to enable EAP-FAST against the WLC controller is to adjust the 802.1x timeout value. In ACS, the default is 20 seconds, but on the Wireless LAN Controller, the default is two seconds. In order for the client to obtain the PAC used for encryption via automatic provisioning on the 7921G, the value must be changed on the WLC to a higher value. The suggested timeout is 20 seconds on the WLC as indicated on page 25 of the 7921G Deployment Guide found on Cisco's Web site. To change the 802.1x timeout on the WLC, telnet or SSH to the controller and enter the following command:
(Cisco Controller) >config advanced eap request-timeout 20(Cisco Controller) >show advanced eapEAP-Identity-Request Timeout (seconds)........... 1EAP-Identity-Request Max Retries................. 20EAP Key-Index for Dynamic WEP.................... 0EAP Max-Login Ignore Identity Response........... enableEAP-Request Timeout (seconds).................... 20EAP-Request Max Retries.......................... 2Encryption
Between the wireless client (7921G) and the Wireless LAN Controller, its is recommended to use the WPA security protocol with TKIP encryption and 802.1x-with-CCKM key management. This is necessary as WPA2 does not provide predictable fast roaming. Figure 5-19 shows the recommended encryption settings as configured on the Wireless LAN Controller.
Figure 5-19 Recommended Encryption Settings
It is important to understand the scope of the encryption as shown in Figure 5-20 as it pertains to XML services. XML traffic between the 7921G phone and the Wireless LAN Controller (WLC) is encrypted as configured on the WLC. After the XML traffic is decrypted on the WLC, it is sent unencrypted as standard http XML flows. Secure HTTP (https) is not currently supported by the 7921G.
Figure 5-20 Scope of Encryption
Authentication Server (ACS)
The Cisco Secure Access Control Server (ACS) provides authentication, authorization, and accounting (AAA) services for users of the wireless network. The ACS server extends the integration of the user database to a number of external user databases. These external user databases can be Microsoft Active Directory or other LDAP-based user directories. In addition to providing authentication services to wireless users, it can also be used to provide administrative access to various network components, such as Integrated Services Routers (ISR) and switches. Restricting access to these systems can not only provide the security necessary for the overall security policy of the healthcare provider, but can also increase availability of the Cisco Imatis Mobile Care solution by preventing unauthorized access.
Note
1:1 WLC Redundancy
Using the example from above, in the event of either 4402 failing, the surviving WiSM LC has additional spare capacity to support the 6 or 25 APs from the failed 4402. If however the WiSM or 6509 in which it is installed fails or has a disruption of connectivity, the surviving 4402s do not have spare capacity to service the additional APs. When employing a 1:1 redundancy strategy, it is critical to perform a case-by-case failure analysis and determine if the design is able to provide a high level of availability as required for Cisco Imatis Mobile Care.
N+1 WLC Redundancy
It is also possible to employ a WLC controller strategy that uses an N+1 approach. When using N+1 architecture, each WLC is configured with a WLC that is designated as a backup WLC in the event of a failure. This controller is not used until there is a failure event upon which all APs using the failed controller switch to the backup WLC. This cost-effective approach provides a high level of availability in the event of a single WLC failure scenario.
The wireless controllers validated as part of the Cisco Imatis Mobile Care solution include the 4400-based controllers running version 4.1.181.0. As such, a few bugs have been discovered as part of the VoWLAN testing and are described in detail in the VoWLAN design guide. To summarize, the mapping between DSCP and CoS is not being performed properly and as such the end-to-end QoS mapping between DSCP and CoS may be lost depending upon what trust model is being used on the switch that is providing connectivity to the WLC. To work around this bug (CSCsi78368—found in 4.1.181 WLC code), it is necessary to trust the DSCP information as it is marked correctly from the WLC. This has been addressed and corrected in version 4.2 of the WLC code. Information about this bug and possible workarounds are discussed in the VoWLAN design guide at the following URL:
Solution Component Interconnections
In this solution, several interconnections between components are required. This section outlines some of the designs principles to consider for those interconnections. These interconnections may connect equipment that spans across a hospital campus and data center. As such, the QoS and high availability designs are critical as these interconnections are implemented.
CUCM to IMATIS Connections
Communication between CUCM and IMATIS uses three interface types:
•
•
•
A system user defined on the BizTalk server will be authorized to use the AXL interface. Each of the BizTalk servers is configured as a primary and backup interface. With two BizTalk servers or more in the BizTalk group, CUCM has more than one BizTalk server to connect in case one BizTalk server fails.
The SNMP interface connects between CUCM and the IMATIS server. When configuring the SNMP interface on the CUCM publisher, an option to "Apply to all nodes" is available and should be configured. Each CUCM server in the cluster is configured with the IMATIS server as the receiver for the SNMP messages. With multiple IMATIS servers in a windows cluster, an IMATIS server should always be available.
The EM proxy interfaces runs through the BizTalk server. The BizTalk server should be configured as a phone would be configured for XML Service Redundancy as outlined in Chapter 6, "Implementing the Cisco Imatis Mobile Care Solution." The CUCM has a virtual IP address defined to access the available CUCM server to serve the request. When the BizTalk server sends the proxy EM request, the request is sent to the virtual IP address for CUCM.
IP Phone to CUCM/IMATIS Connections
IP phones should always be configured with the virtual IP address for CUCM and the IMATIS servers for an XML request. Using this virtual IP address ensures that the available CUCM or IMATIS server always serves the request from the IP phone. On the IMATIS server, both the Windows clustering and BizTalk group ensure that the application is always available to the phone. For the CUCM server, the XML services redundancy configuration ensures XML services are always available from one of the CUCM servers in the cluster.
IP phone redundancy to CUCM clusters for services other than XML services, such as call signaling, should use the design guidelines as outlined in the CUCM 6.0 SRND.
Hospital Equipment to IMATIS Adapters
Connections between the IMATIS adapters and the hospital equipment, such as nurse call systems, ancillary systems, and building and fire alarm systems, needs to be evaluated. As each hospital's equipment may have unique product capabilities, the analysis should be performed during the integration. For RS-232 interfaces, there are active/passive splitters that allow for a faster switch to the active connection from a server that uses RS-232 connections.
Voice Gateway to Nurse Call System
In order to provide voice access to legacy nurse call and PBX systems, the use of a Voice Gateway may be required. The most common uses case as it relates to nurse call is a voice call back to the patient room or ancillary department. In addition, offnet communication can also be accomplished from any of the Cisco Imatis Mobile Care endpoints through the very nature of Unified Communication. To provide this connectivity, the use of an Integrated Services Router with an appropriate voice interface is one possible solution. The other alternatives include various voice-capable line cards available for the Cisco Catalyst 6500 series platform.
As part of the Cisco Imatis Mobile Care validation process, a 3875 ISR was used with FXS ports which provide connectivity to nurse call and PBX-based systems. From a high availability perspective, it is recommended that redundant voice gateways be used within the Cisco Imatis Mobile Care solution. To utilize redundant voice gateways, a route group can be defined that specifies the order in which trunks or voice gateways are utilized for any given route pattern. In the event that a Voice Gateway fails or is no longer reachable, Call Manager automatically removes that gateway from the list of configured gateways and continues routing calls through the surviving configured gateways.
When connecting redundant voice gateways to PBXs, its recommend that each voice gateway be connected to PBX ports that are contained on separate PBX shelves in order to provide a level of fault tolerance in the event of a failure or scheduled maintenance of the shelf.
Network Services Integration
Active Directory and Cisco Secure ACS
The Cisco Imatis Mobile Care solution interfaces with and uses a number of different network services. Active Directory integration is supported as a means to authenticate wireless users through the use of the Cisco Secure ACS solution. The IMATIS suite of applications also takes advantage of Active Directory to provide user assignment. This greatly simplifies the assignment of roles to users, as once the user is defined to Active Directory, the userid appears within the IMATIS User Manager application.
DNS (Domain Name Services)
Both redundancy and completeness of domain naming information should be included in the overall design of the network. Many hosts depend upon the ability to correctly resolve the host name of a server. In the case of the Cisco Imatis Mobile Care solution, both the 7921G and 7971G phones require that the hostname of the middleware XML-based service host be resolvable. Each time the services key is pressed, for example, the URL configured for that key on the phone is referenced. If the URL contains a hostname-based URL, a DNS query is performed by the phone in order to resolve the supplied name to its corresponding IP address.
If during this time DNS services are inhibited or unavailable for some reason, the overall availability and end user perceived reliability of the solution deteriorates. In order to provide a high level of service availability, redundant DNS servers should be employed and connected to the network using diverse switching fabric. Similar to that of the DHCP servers, each DNS server should be placed on separate maintenance windows to prevent issues arising due to hardware or software updates. Both the 7921G and 7971G do not cache DNS queries which relate to a DNS query for each XML service selected from the phones menu.
DNS for XML High Availability
In order to increase the availability of the XML services as accessed from a Cisco handset, it is recommended that either Server Load Balancing (SLB) be utilized or an appliance-based load balancing solution be implemented, such as the ACE appliance or Content Services Switch (CSS). Alternatively, it is possible to use round robin DNS to provide round robin IP address resolution for each of the configured Call Managers in the Unified Communications cluster. With round robin DNS, each successive DNS request made issues the next IP address for a given hostname in a circular fashion. In the event of a failed Call Manager, or a Call Manager which no longer has access to the network, this IP address is still resolved. While this is a disadvantage to round robin DNS, it does provide the end user with the ability to press the services button, for example, and have a possibility of receiving an IP address for one of the surviving Call Managers in the cluster. Equally, however, it is possible that during the time that user A experienced the address of the failed Call Manager, another user B may have obtained the address for the surviving Call Manger. The next time that user A requests services, they would again receive the failed server IP address until such time that their request results in one of the surviving Call Manager IP address being returned. For this reason, round robin DNS is not recommended for a high availability-based solution for Cisco Imatis Mobile Care over that of SLB or an appliance-based approach. It is included here to discuss its capabilities and limitations on the overall user experience.
Network Time Protocol
While availability is not typically affected by Network Time Protocol (NTP), it can provide valuable assistance in determining the sequence of events that lead to a disruption of service. In addition, having the time synchronized between the phone, middleware vendor servers, network infrastructure, and ancillary systems can become important when tracing the delivery of messages as they traverse the overall solution. Implementing a redundant and hierarchal NTP design can provide valuable information during troubleshooting, hopefully resulting in the reduction of service interruptions.
