About Call Admission Control
The Oracle® Enterprise Session Border Controller provides call admission control capabilities based on the following policies:
- Bandwidth (single and multi-level policies)
- Session capacity
- Session rate (sustained and burst)
Note:
In order to provide admission control for networks to which the Oracle® Enterprise Session Border Controller is not directly connected, you need to define multiple realms per network interface.
Bandwidth-Based Admission Control
The Oracle® Enterprise Session Border Controller is a policy enforcement point for bandwidth-based call admission control. Sessions are admitted or rejected based on bandwidth policies, configured on the Oracle® Enterprise Session Border Controller for each realm.
To manage bandwidth consumption of a network’s overall capacity, you can configure aggregate bandwidth policies for each realm.
As the Oracle® Enterprise Session Border Controller processes call requests to and from a particular realm, the bandwidth consumed for the call is decremented from the bandwidth pool for that realm. The Oracle® Enterprise Session Border Controller determines the required bandwidth from the SDP/H.245 information for SIP and from the OLC sent in the SETUP message for H.323. Any request that would cause the bandwidth constraint to be exceeded is rejected with a SIP 503 Service Unavailable or an H.323 Release Complete.
For example, if an incoming SIP message requests PCMU for a payload/encoding name, a zero (0) payload type, and an 8000 cycle clock rate, the Oracle® Enterprise Session Border Controller must determine how much bandwidth is needed.
To accomplish this task, the system checks the media profile values and reserves the bandwidth required for flows. If the required bandwidth for the new flow exceeds the available bandwidth at the time of the request, the Oracle® Enterprise Session Border Controller rejects the session.
With these mechanisms, the Oracle® Enterprise Session Border Controller provides bandwidth-based admission control.
Multi-Level Bandwidth Policy Nesting
Multi-level nesting of bandwidth policy enforcement addresses the following issues:
- Bandwidth over-subscription: access or transit transport networks are aggregated and/or oversubscribed. For example, digital subscriber lines (DSL), Frame Relay (FR), and Asynchronous Transfer Mode (ATM). Admission control policies must reflect access network topology.
- Bandwidth partitioning for multiple services: access or transit bandwidth is partitioned among multiple service profiles (SIP, for example) in the same customer network.
- Multi-site VPN environments: admission control must be applied at the site level as well as the VPN level.
The following example illustrates different scenarios; in each there are two or more levels of admission control required. Nested admission control is best depicted by the DSL broadband example.
In DSL access networks, ATM network bandwidth is typically oversubscribed at rates up to 400/1. At Level 3 (above), hundreds of users virtual circuits (VCs) are aggregated to a smaller set of virtual paths (VPs) at each DSLAM. At Level 2, many virtual paths are aggregated at the first ATM switch. Finally, at Level 1, all traffic from all subscribers in the access network is aggregated at the BRAS. Each level of aggregation is oversubscribed, creating the need to perform admission control at each level.
From a Oracle® Enterprise Session Border Controller perspective, multiple tiers of realms are supported, each with its unique bandwidth policy. Only the lowest order realm (Level 3) requires an address prefix (that assigned to the DSLAM) that must be used by the Oracle® Enterprise Session Border Controller to determine in which realm a user resides. When a call request to or from a particular user is received, the Oracle® Enterprise Session Border Controller checks each realm in the path to determine whether sufficient bandwidth is available to place the call.
Session Capacity- and Rate-based Admission Control
A session agent defines a signaling endpoint. It is a next hop signaling entity that can be configured to apply traffic shaping attributes. You can define concurrent session capacity and rate attributes for each session agent.
You can configure a set of attributes and constraints for each session agent to support session access control. In this configuration, the Oracle® Enterprise Session Border Controller only accepts requests from configured session agents. And you can set up session admission control so that the Oracle® Enterprise Session Border Controller limits the number of concurrent inbound and outbound sessions for any known service element.
The Oracle® Enterprise Session Border Controller denies a call request to any destination that has exceeded its configured policies for session capacity and session rate. The Oracle® Enterprise Session Border Controller might reject the call request back to the originator. If multiple destinations are available, the Oracle® Enterprise Session Border Controller will check current capacity and rate for each destination and attempt to route the call only to destinations whose policy limits have not been reached.
You assign a media profile to a session agent and indicate whether the transport protocol is SIP or H.323. If the protocol is H.323, you need to indicate whether the session agent is a gateway or a gatekeeper.
Constraints for Proxy Mode
The Oracle® Enterprise Session Border Controller applies session router and session agent constraints when it is in proxy (transaction or stateless) mode if you enable the ACLI constraints parameter for a session agent. However, the Oracle® Enterprise Session Border Controller does not track SIP sessions when in transaction mode, so the following session-specific constraints are not applied:
- max-sessions
- max-inbound-sessions
- max-outbound-sessions
- min-seizures
- min-asr
Constraints the Oracle® Enterprise Session Border Controller applies are:
- max-burst-rate
- max-inbound-burst-rate
- max-outbound-burst-rate
- max-sustain-rate
- max-inbound-sustain-rate
- max-outbound-sustain-rate
In order to set the desired time windows for computing burst rates and sustain rates, you also need to configure these parameters in the session agent configuration: burst-rate-window and sustain-rate-window. You can also set the time-to-resume and in-service-period parameters to control how long to wait before bringing a session agent back into service after its constraints are no longer exceeded.
CAC Policing and Marking for non-Audio non-Video Media
The Oracle® Enterprise Session Border Controller supports non-AVT (audio-visual transport) media profile and media policy configurations.
In previous releases, the Oracle® Enterprise Session Border Controller only policed media based on average rate limits configured in media profiles, but these are only applied to AVT. And if there are not required bandwidth or average rate limit values set for the media profile, CAC and policing functions are not applied to media—even if the SDP specifies appropriate bandwidth values. Likewise, ToS markings are not applied for non-AVT media, but only for SIP, H.323, and AVT media types.
With this feature addition, you can now enable your Oracle® Enterprise Session Border Controller to handle non-AVT media types like image and text, and use application and data type for policing purposes. Bandwidth CAC support has also been added for non-AVT media types, as has support for the application specific (AS) bandwidth modifier (b=AS:<value>) in the SDP with specification of a defined amount of headroom for that value.
Bandwidth CAC Fallback Based on ICMP Failure
For networks where backup links (operating in active-standby mode) from CE-routers to the MPLS backbone are provisioned with less bandwidth than the primary links, the Oracle® Enterprise Session Border Controller can:
- Detect remote link failures
- Trigger bandwidth updates at the realm level when using backup links
- Detect remote link failback to primary
To do so, the Oracle® Enterprise Session Border Controller monitors the primary link status using ICMP echo requests (or pings). It issues the pings at regular intervals, forming a heartbeat mechanism. The CE-router can respond to these pings on the primary link, which is represented by the WAN IP address. When this link fails over, the backup link assumes the same WAN IP address but is not responsive to the pings. This way, the Oracle® Enterprise Session Border Controller determines failover when the ICMP ping fails.
When there is an ICMP ping failure, the Oracle® Enterprise Session Border Controller adjusts the realm’s available bandwidth pool from its maximum bandwidth setting to its fallback setting. If the fallback amount is less than the maximum amount, it is possible for the Oracle® Enterprise Session Border Controller to start rejecting calls. It does so until enough calls are released to free adequate bandwidth to stay under the fallback limit and still accept calls.
Bandwidth CAC Fallback Based on ICMP Failure Configuration
You can set up ICMP heartbeats and fallback bandwidth pools in the realm configuration. Leaving the icmp-detect-multiplier, icmp-advertisement-interval, or icmp-target-ip parameters blank or set to zero turns the feature off.
To enable bandwidth CAC fallback based on ICMP failure:
Bandwidth CAC for Aggregate Emergency Sessions
You can configure the maximum amount of bandwidth on your Oracle® Enterprise Session Border Controller you want used specifically for priority (emergency) calls in the realm configuration’s max-priority-bandwidth parameter. You set this limit on a per-realm basis, and the limit is enforced for nested realms. Setting a bandwidth limit specifically for priority calls allows the Oracle® Enterprise Session Border Controller to reject calls exceeding the threshold, and also to accept calls that exceed the bandwidth limit for non-priority calls (set in the max-bandwidth parameter).
The bandwidth limit for emergency calls operates in conjunction with the bandwidth limits you can set for all other types of calls. When an emergency call comes in, the Oracle® Enterprise Session Border Controller checks the non-priority bandwidth limit. If bandwidth is sufficient, the call goes through and the Oracle® Enterprise Session Border Controller decrements the bandwidth used from the pool of the amount available.
However, if a priority call exceeds the max-bandwidth setting, the Oracle® Enterprise Session Border Controller checks the max-priority-bandwidth parameter. If is it within the limit for priority calls, the system allows the call and decrements the amount of used bandwidth from what is available.
When there is not enough bandwidth in either the priority or non-priority pool, the Oracle® Enterprise Session Border Controller rejects the call with the corresponding error code and reason phrase.
Any bandwidth subtracted from either pool during a session is returned to that pool as soon as the session ends.