Wednesday, December 02, 2009

What is LTE

Introduction
LTE (Long Term Evolution) is the preferred development path of GSM/W-CDMA/HSPA networks currently deployed, and an option for evolution of CDMA networks. This essential evolution will enable networks to offer the higher data throughput to mobile terminals needed in order to deliver new and advanced mobile broadband services.

The primary objectives of this network evolution are to provide these services with a quality at least equivalent to what an end-user can enjoy today using their fixed broadband access at home, and to
reduce operational expenses by means of introducing flat IP architecture.

Why LTE
lthough 3G/3.5G technologies such as HSPA/EV-DO deliver significantly higher bit rates than 2G technologies, they do not fully satisfy the “wireless broadband” requirements of instant-on, always-on and multi-megabit throughput. With LTE delivering even higher peak throughput and much lower latency, mobile operators (either 3GPP or 3GPP2 based) have a unique opportunity to evolve their existing infrastructure to next- generation wireless networks. These networks will deliver their subscriber’s Quality of Experience (QoE) expectations in terms of real-time services such as Voice Over IP, Multi-User Gaming Over IP, High Definition Video On Demand and Live TV. This will also continue to improve the quality of delivery for all legacy applications (e-mail, internet browsing, MMS, etc.)

The improved speed and low latency provided by LTE will offer a much improved end-user experience for all corporate services:
• For applications where data throughput is important - faster e- mail and file uploads, enhanced VPN connection, high-speed internet, etc. and;
• For interactive applications where latency is crucial - IMS based VoIP, mail and file synchronization with an on-line server, peer-to-peer applications such as “NetMeeting”, SIP multimedia services including video and voice conference over IP, application sharing, etc.

In addition to typical corporate applications, we expect an increased interest from the vertical markets where information accuracy, reliability and immediacy are key: medical applications where latency and high resolution imaging are highly important; machine-to-machine communication where security and immediacy are crucial; live network based navigation; etc. The mass market will benefit from improvements delivered by LTE for all person-to-person and internet community applications: Push-to-See, improved quality for VoIP, photo and video downloading / uploading for personal blogs, online gaming, mobile social networks (such as YouTube, myspace), and “Second
life” type applications etc. On top of those improvements, LTE will enable the introduction of new services, such as High Definition Video (or HD TV) and multi-user interactive gaming:
• HD TV requires between 10 to 20 Mbits/s bandwidth (18 Mbits/s for example with Blue Ray standard), which is higher than current HSPA capabilities.
• Interactive multi-user gaming is extremely sensitive to latency: the very low latency offered by LTE (less than 10ms versus 60ms with HSPA) is key for fighting games, car races, or any action games involving a large number of simultaneous users. In addition, the higher throughput offered will enable high-resolution video games. Lastly LTE will play a key role in the development of N-uple services at home (IP TV, Internet, telephone, mobile…services bundle). We are observing an increasing need for broadband access at home and the same will apply to mobile services for two main reasons. Firstly, as subscribers become used to higher speeds at home, they will require the same quality of service when they are mobile so as to benefit from a seamless experience. The second reason is the possibility of offering higher bandwidth in remote areas where ADSL throughput is no longer sufficient and fibre
may not be economically viable compared with LTE. In those areas the same LTE infrastructure will deliver mobile services as well as broadband access at home, bringing economies of scale.

With the recent introduction of HSDPA and EV-DO Rev A, we have observed a significant increase in mobile data traffic, with some operators quadrupling their Packet Switched traffic in one
year. At this growth rate, and with the proliferation of new applications on the network, cells in hot spots will be quickly saturated and the network will require densification in these overloaded areas. This can be delivered by using a higher capacity solution such as LTE.

LTE and Multimedia Broadcast Multicast Service The Multimedia Broadcast Multicast Service (MBMS) enables multiple users to receive data over the same radio resource. This creates a more efficient approach for delivering content, such as video programming, to which multiple users have subscriptions. However, with HSPA, MBMS does not match the capabilities of broadcasting and/or broadband wireless technologies (such as DVB-H or WiMAX). With an OFDM/SC-FDMA (Orthogonal Frequency Division Multiplex /Single-Carrier Frequency Division Multiple Access) system, LTE provides the possibility of operating MBMS in a single frequency network mode where significant performance gains (up to five times existing capacity) can be achieved without additional receiver complexity. LTE will consequently dramatically enhance MBMS, and match DVB-H and WiMAX, capabilities.

Reducing the Total Cost of Ownership Another key driver behind LTE is the reduction of the cost per
byte, which is expected to decrease by a factor of six compared with HSPA today. This cost reduction is derived from network simplification, with flat IP architecture and the enhanced capacity delivered by the new radio technologies implemented by LTE.


What Is LTE Technology?
In order to prepare for wireless operator’s future needs and to ensure the competitiveness of their mobile systems over the next ten years, a progression of network architecture, as well as an evolution of the radio interface is required. This is being evaluated in the 3GPP System Architecture Evolution (SAE), Long Term Evolution (LTE) and HSPA Evolution (HSPA+) Study Items. From a network deployment perspective it is likely that HSPA enhancements will be introduced first followed by the progression to a radio interface (LTE). LTE will allow operators to achieve even greater peak throughputs in higher spectrum bandwidth, and to benefit from greater capacity at a reduced cost. Initial deployments are targeted for 2009.
LTE characteristics include:
• Peak LTE throughputs (high spectral efficiency)
− DL: 100 Mb/s SISO (Single Input Single Output);
− 173 Mb/s 2x2 MIMO (Multiple Input Multiple Output);
− 326 Mb/s 4x4 MIMO; for 20 MHz
− UL: 58 Mb/s 16 QAM
− 86 Mb/s 64 QAM (based on 1 Tx UE)
• Increased Spectrum efficiency over Release 6 HSPA
− DL: 3-4 times HSDPA for MIMO (2,2)
− UL: 2-3 times E-DCH for MIMO(1,2)
• Ultra low Latency
− less than 10 msec for round-trip delay (RTD) from UE to
server
− Reduced call setup times (50-100ms)
− =>wired user experience
• Capacity per cell
− 200 users for 5 MHz, 400 users in larger spectrum
allocations
• Flexible spectrum use maximizes flexibility
− 1.4, 3/3.2, 5, 10, 15, 20 MHz
− All frequencies of IMT-2000: 450 MHz to 2.6 GHz
LTE is being developed by the 3GPP (3rd generation Partnership Project) standards body that is also responsible for GSM and W-CDMA. LTE standards are currently being developed and are expected to be finalized in early 2008. In order to reach this performance, LTE will make the best use of the latest technologies on the market. For radio, a new modulation scheme is being used based on OFDM, and the latest antenna technologies, such as MIMO will be deployed. For the core network, an IP based network topology will also be introduced to considerably reduce network complexity. LTE uses Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink, which is better suited than W-CDMA for achieving high peak data rates in high spectrum bandwidth. On the uplink LTE uses SC-FDMA (Single Carrier Frequency Division Multiple Access), a technology that provides advantages in power efficiency and resulting terminal battery life versus a pure OFDM approach.

MIMO refers to a technique that employs multiple transmit and receive antennas, often in combination with multiple radios and parallel data streams. This results in numerous data paths effectively operating in parallel and, through appropriate decoding, a multiplicative gain in throughput. For example, with a 2X2 MIMO system, a gain of a factor of 2 is expected on the peak
throughput. LTE also requires new network architecture, with the main functional entities being: the e-node B on the access side, and the Serving (S) and Packet Data Network (PDN) gateways and the
Mobile Management Entity (MME) in the core network, as depicted in the figure below.

LTE is a pure packet system, with no support for legacy circuit- switched voice/data. This shift allows a significant simplification of the network, reducing the number of nodes and improving operational efficiencies. This network simplification also removes any bottlenecks from the system, ensuring the network permanently runs at peak efficiency. The next figure shows the impacts of this simplification comparing traditional UMTS elements and LTE nodes, and provides a macroscopic mapping of User Plane and Control Plane between nodes.



In contrast to UMTS architecture, no Radio Network Controller (RNC) is required: the RNC’s functions are collapsed into the eNodeB. On the Core network side, the Mobility Management Entity (MME) assumes the role of the SGSN for the control plane, and the serving and PDN gateways ensure the role of user plane, routing user data traffic to the network edge, replacing the GGSN.

Tuesday, October 13, 2009

A peek into the (not-so-distant) future of wireless broadband

What are the applications and services LTE will make possible? Check out this video to find out! Connected car, crowdcasting, mobile e-commerce… these are some of the reasons people in this video are so happy!



Source: Alcatel-Lucent blog.

Tuesday, July 07, 2009

Ping & Traceroute Troubleshooting Example

In this example, a ping to 186.9.17.153 gave a “TTL timeout” message. Ping TTLs will usually only timeout if there is a routing loop in which the packet bounces between two routers on the way to the target. Each “bounce” causes the TTL to decrease by a count of one until the TTL reaches zero at which point you get the timeout.

The routing loop was confirmed by the traceroute in which the packet was proven to be bouncing between routers at 186.40.64.94 and 186.40.64.93.

G:\>ping 186.9.17.153

Pinging 186.9.17.153 with 32 bytes of data:

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Ping statistics for 186.9.17.153:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

G:\>tracert 186.9.17.153

Tracing route to lostserver.confusion.net [186.9.17.153]

over a maximum of 30 hops:

1 <10>

2 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

3 70 ms 71 ms 70 ms rtr-1.confusion.net [186.40.64.93]

4 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

5 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

6 60 ms 70 ms 61 ms rtr-2.confusion.net [186.40.64.94]

7 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

8 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

9 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

...

...

...

Trace complete.

This problem was solved by resetting the routing process on both routers. The problem was initially triggered by an unstable network link that caused frequent routing recalculations. The constant activity eventually corrupted the routing tables of one of the routers.


Possible Reasons For Failed Traceroutes

Traceroutes can fail to reach their intended destination for a number of reasons, these include:

o Traceroute packets are being blocked or rejected by a router in the path. The router immediately after the last visible one is usually the culprit. It’s usually good to check the routing table and/or other status of this next hop device.

o The target server doesn’t exist on the network. It could be disconnected, or turned off. (!H or !N messages may be produced.)

o The network on which you expect the target host to reside doesn’t exist in the routing table of one of the routers in the path (!H or !N messages may be produced.)

o You may have a typographical error in the IP address of the target server

o You may have a routing loop in which packets bounce between two routers and never get to the intended destination.

o The packets don’t have a proper return path to your server. The last visible hop being the last hop in which the packets return correctly. The router immediately after the last visible one is the one at which the routing changes. It’s usually good to:

v log on to the last visible router.

v Look at the routing table to determine what the next hop is to your intended traceroute target.

v Log on to this next hop router.

v Do a traceroute from this router to your intended target server.

v If this works: Routing to the target server is OK. Do a traceroute back to your source server. The traceroute will probably fail at the bad router on the return path.

v If it doesn’t work: Test the routing table and/or other status of all the hops between it and your intended target.

Note: If there is nothing blocking your traceroute traffic, then the last visible router of an incomplete trace is either the last good router on the path, or the last router that has a valid return path to the server issuing the traceroute.

Sunday, May 24, 2009

ITIL Fundamental

General Overview

ITIL Service Support Processes (Operational Processes):
• Configuration Management
• Incident Management
• Problem Management
• Change Management
• Release Management

ITIL Service Delivery Processes (Strategic Processes):
• Availability Management
• IT Services Continuity Management
• Capacity Management
• Financial Management
• Service Level Management

ITIL Functions (Non-Process):
• Service Desk

Configuration Management
Summary: Configuration Management provides information on the IT infrastructure
to other ITIL processes and for decision support by IT Management. Configuration
Management enables control of the infrastructure by monitoring and maintaining
information on:
• All the resources needed to deliver services
• Configuration item (CI) status and history
• Configuration item relationships

Specific Configuration Management tasks:
• Identification and naming
• Management information
• Verification
• Control
• Status Accounting

Tip: A configuration Item (CI) is different than an Asset, which is a component of
a business process such as human resources (people), computer systems,
stationary/paper, telephones, etc.
Configuration Management Database (CMDB): A database, which contains all
relevant details of each Configuration Item (CI) and details of important
relationships between CIs.


A Configuration Item (CI):
• Is needed to deliver a service
• Is uniquely identifiable
• Is subject to change
• Can be managed

A Configuration Item (CI) has:
• a category
• one or more relationships
• one or more attributes
• a specific status at any given point in time

Configuration Item (CI) Variant: A Configuration Item (CI) that has the same
basic functionality as another Configuration Item (CI) but is different in some
small way (ex: has more memory)

Configuration Baseline: A snapshot of the state of a Configuration Item and any
component or related Configuration Items, frozen in time for a particular purpose
(such as the ability to return a service to a trusted state if a change goes wrong)

Configuration Management is critical in supporting and furthering the maturity of
all other ITIL service support and delivery processes.

Service Desk
The Service Desk concentrates on incident lifecycle management and performs the
following primary functions:
• Customer Interface
• Business Support
• Incident Control
• Management Information

Tip: Remember that the Service Desk is not a process, but is an IT function.

The Service Desk is the primary point of contact for all internal and/or external
customers and handles:
• Calls
• Questions
• Requests
• Complaints
• Remarks

The goal of the Service Desk is to:
1. To restore the service as quickly as possible
2. To manage the incident life-cycle (coordinating resolution)
3. To support business activities
4. To generate reports, to communicate and to promote

The different Types of Service Desks include:
• Call Centers: Handles large volumes of general support calls generally via
telephone.
• Help Desks: Manages, coordinates, and resolves incidents as quickly as
possible.
• Service Desks: Handles incidents, problems, questions and requests for
customers submitted through one or more interface points.

Tip: for incidents (an unexpected disruption to agreed service), the Service Desk
sets a priority based on business impact and urgency. Correctly assessing priorities
enables optimal deployment of resources in the best interest of the customer.

Incident Management
Incident: Any event which is not part of the standard operation of a service and
which causes or may cause an interruption to or a reduction in the quality of that
service.

The goal of Incident Management is to restore normal service as quickly as possible,
with the additional objectives of:
• Minimizing adverse impact of incidents on business operations
• Ensuring that the best possible levels of service quality and availability are
maintained according to established Service Level Agreements (SLAs).

Work-Around: Method of avoiding an incident or problem.

Service Request: Requests not related to incidents or failures in the IT
environment.

Problem: The unknown root cause of one or more incidents.

Known Error: A condition that exists after successfully diagnosing the root cause of
a problem; one or more specific Configuration Items (CIs) are determined to be at
fault.

Category: Classification of a group of incidents (e.g. Application, Hardware,
Network, etc.).

Vertical Escalation: Incident(s) escalate up the management chain.

Horizontal Escalation or Referral: Incident(s) escalate across different knowledge
groups or IT domains.

Primary activities in the Incident Management Life-Cycle:
• Acceptance / logging
• Registering events
• Consult the CMDB
• Classification
• Resolution
• Closure

Incident reporting includes:
• Daily reviews of incident and problem status against service levels
• Weekly management reviews
• Monthly management reviews
• Proactive service reports

Problem Management
The goal of Incident Management is to stabilize IT services through the following
activities:
• Determine the root causes of incidents
• Remove root cause points of failure
• Prevent incidents and problems proactively
• Minimize the consequences of incidents
• Prevent recurrence of incidents related to errors
• Improve the productive use of resources

Specific Problem Management tasks include:
• Facilitate Problem Control
• Implementing Error Control
• Proactive Problem Prevention
• Identifying Problem Trends
• Providing Management Information
• Performing Post Implementation Reviews (PIR)

Tip: The primary difference from the Incident Management process is Problem
Management’s proactive approach towards eliminating inefficiencies from the IT
environment.


Primary process inputs:
• Incident details
• Configuration details
• Defined workarounds

Primary process outputs:
• Known Errors (KE)
• Requests for Change (RFC)
• Updated Problem records including:
o Workarounds
o Solutions (Fixes)
• Management information matching

The Problem Control sub-process includes:
• Identification
• Classification
• Assign Resources
• Investigation and Diagnosis
• Establish Known Error

The Error Control sub-process includes:
• Error Identification and Recording
• Error Assessment
• Recording Error / Resolution (Send out RfC)
• Error Closure

Known Error: An Incident or Problem for which the root cause is known and a
temporary workaround or permanent alternative has been identified.

Proactive Problem Management involves:
• Trend Analysis
• Targeting Support Action
• Providing Information to the Organization

Change Management
The goal of Change Management is to implement approved changes efficiently,
cost-effectively and with minimal risk to existing and new IT infrastructure
components.

Tip: Only approved changes should be performed in order to reduce overall risk
to the IT environment.

Specific tasks in the Change Management process include:
• Filtering Changes
• Managing Change Process
• Managing Changes
• Chairing CAB and CAB/EC
• Review and Closure
• Management Information

The process inputs include:
• Requests for Change (RfC)
• CMDB / CI data
• Forward Schedule of Changes (FSC)

The process outputs include:
• Forward Schedule of Changes (FSC)
• Requests for Change (RfC)
• CAB minutes and action items
• Change Management reports

The impact categorization of changes may include:

Category 1
• Little impact on current services
• Change Manager may authorizes Requests for Change (RfC)

Category 2
• Clear impact on services
• RfC must be reviewed by the Change Advisory Board (CAB)
• Change Manager requests advice prior to authorization and planning

Category 3
• Significant impact on the service to the business
• Considerable resources required for change
• RfC is reviewed and approved by the Change Advisory Board (CAB)

Change Management priority settings may include:

Urgent: Change is required now to avoid severe adverse business impact

High: Change needed as soon as possible; may be potentially damaging to
business service provision

Medium: Scheduled changes intended to fix minor errors or issues with
functionality

Low: Change leads to minor improvements

Change: The addition, modification, or removal of approved and/or supported
hardware, software, applications and other environment components, systems, and
related documentation.

Request for Change (RfC): Formal request and recording of details surrounding the
intended change to the IT environment, impacting one or more Configuration Items
(CIs).

Forward Schedule of Changes (FSC): Schedule that contains details of and timing
for all approved changes scheduled for implementation.

The primary Change Management process activities include:
1. Request for Change (RfC)
2. Registration & Classification
3. Monitoring & Planning
4. Approval
5. Building & Testing
6. Authorizing Implementation
7. Implementation
8. Evaluation

Tip: Additional Change Management considerations:
• Change backout plan(s) should always be in place prior to implementation
• All changes should be reviewed prior to implementation

Release Management
The primary goal of Release Management is safeguard all hardware, software and
related items within the IT environment by ensuring the deployment of authorized
and tested versions of hardware and software.

Specific Release Management tasks include:
• Defining release policies
• Control of the Definitive Software Library (DSL)
• Control of the Definitive Hardware Storage (DHS)
• Distribution of software and associated Configuration Items (CIs)
• Execution of software audits
• Managing software releases
• Managing software builds

Tip: Releases are performed in conjunction with and under the control of the
Change Management process.

Definitive Software Library (DSL): Reliable versions of software in a single logical
location.

Tip: Software need not be centrally located in a DSL and may be physically
stored at different locations.

The Release Management policy should include:
• Release Unit
• Full / Package / Delta Releases
• Numbering
• Frequency
• Emergency Change

Release Management version control should include:
• Development
• Testing
• Production Release (Go-Live)
• Archiving

The primary activities within the Release Management process should include:
• Software Control & Distribution (Operational Release)
• Change Management (Release Control)
• Configuration Management (Release Control & Administration)

Availability Management
The primary goal of Availability Management is to predict, plan for and manage the
availability of services by ensuring that:
• All services are underpinned by sufficient, reliable and properly maintained
Configuration Items (CIs)
• Appropriate contractual agreements with third party suppliers are in place (if
applicable)
• Changes are proposed to proactively prevent future loss of service availability

Tip: Availability Management is critical to ensuring IT organizations deliver the
levels of availability agreed upon with customers through Service Level
Agreements (SLAs).

The primary attributes of Availability Management include:
• Reliability
• Maintainability
• Resilience (Redundancy)
• Serviceability

Tip: Availability Information may be stored in an Availability Database (ADB).
Availability information is used to create Availability plan(s), dictated by the
Service Level Management process.

Mean Time to Repair (MTTR): Downtime; period of time that elapses between the
detection of an incident and actual resolution.

MTTR Lifecycle: Incident, Detection, Diagnosis, Repair, Recovery, Restoration.

Mean Time Between Failures (MTBF): Uptime; time period that elapses between
restoration of an incident and a new recurrence of the same incident.

Mean Time Between System Incidents (MTBSI): Time period that elapses
between two incidents.


IT Service Continuity Management
The primary goal of IT Service Continuity Management (ITSCM) is to support the
Business Continuity Plan (BCP) process by ensuring the IT environment can be
recovered within required timeframes.

Tip: An IT Service Continuity Plan cannot be created without the existence of a
valid Business Continuity Plan (BCP).

An ITSCM plan is important in order to:
• Reduce the impact of IT infrastructure failure
• Decrease business risk and vulnerability
• Increase customer and end-user confidence
• Fulfillment of legal and/or regulatory requirements

A Business Impact Analysis (BIA) includes the following components:

Risk Analysis
• Determining the value of assets
• Determining threats
• Determining vulnerabilities

Risk Management
• Outlining countermeasures
• Planning for potential disasters
• Managing a disaster

Infrastructure options specific to the ITSCM process include:
1. Do Nothing
2. Manual Workarounds
3. Reciprocal Arrangements
4. Gradual recovery (“Cold Standby”)
5. Intermediate Recovery (“Warm Standby”)
6. Immediate Recovery (“Hot Standby”)

An effective IT Service Continuity Management (ITSCM) plan should include the
following sections:
• IT Administration
• Infrastructure Overview
• Operating Procedures
• IT Personnel
• IT Security
• Contingency Site(s)

Testing and reviewing the ITSCM plan should include the following activities:
• Initial Review (immediate / initial sign-off)
• Continuous Review (e.g. every 6 to 12 months)
• Post-Implementation (e.g. after an actual recovery has occurred)
• Documentation Reviews (and continuous updates)
• Adherence to all Change Management requirements

Capacity Management
The primary goal of Capacity Management is to determine the appropriate and
cost-justifiable capacity of IT resources to ensure that agreed-upon service levels
are achieved within the required timeframes.

Specific objectives are achieved through:
• Demand Management (Business Capacity Management)
• Workload Management (Service Capacity Management)
• Resource Management (Resource Capacity Management)
• Performance Management of:
o Internal and external financial data
o Usage data

Capacity Data Base (CDB): Contains all measurements and associated metrics
used to create a Capacity Management Plan; populated with Performance
Management data used for decision support related to:
• Customer capacity requirements / demands
• Workload management
• Performance management
• Capacity planning
• Defining capacity thresholds
• Monitoring capacity

Application Sizing: Estimates resource requirements in support of a proposed
application change, ensuring all required service levels are met.

• Capacity Management Modeling includes:
• Trend Analysis
• Analytical Modeling
• Simulation Modeling
• Baseline Models

IT Financial Management
The primary goal of IT Financial Management is to provide information and
control over the cost of delivering IT services delivered to business customers.

Specific cost units include:
• Equipment Cost Units (ECU)
• Organization Cost Units (OCU)
• Transfer Cost Units (TCU)
• Accommodation Cost Units (ACU)
• Software Cost Units (SCU)

Transfer Costs: Costs incurred by IT, acting as an agent for the customer, but
not allocated against the IT budget.

IT Financial Management cost types include:
• Fixed: Costs unaffected by the level of usage
• Variable: Varying costs according to level of usage
• Direct: Costs associated with the usage of a specific service
• Indirect (Overhead): Costs specific to more than one specific service
• Capital: Costs that are not diminished by usage
• Revenue (Running): Costs that diminish with usage

Specific Financial Management pricing options may include:
• No Charging: IT performs service support and delivery as a support
center
• Cost Recovery: IT performs as a service center
• Notional Charging (Cost Center): IT performs services as a cost center
• Actual Charging: Specific charges for IT products and services charged
by actual usage of these services
• Cost Price Plus (Market Pricing): IT provides services for / as a profit
center

Soft Charging: Used by Support and Cost centers to facilitate service provision
without actual exchange of currency.

Hard Costing: Money for IT services transferred between [bank] accounts
and/or departments

Tip: Profit centers focus on the value of the IT service to the customer

Three primary sub-processes of IT Financial Management include:

Budgeting: Predicting and controlling spending within through periodic
negotiation cycles to set budgets and regular, consistent monitoring of
budgets.

IT Accounting: Enabling the IT organization to fully account for expenditures
by breaking down costs by specific customer, service and/or activity.

Charging: Billing customers for actual services provided through established,
proven IT accounting methods and ongoing analysis, billing, and reporting
procedures.

Tip: Mature IT Financial Management helps streamline IT service by shaping
customer demand for services that have specific, tiered levels of service.

Service Level Management
The primary goal of Service Level Management is to obtain a balance between
the demands for and supply of specific IT services through ongoing facilitation
and negotiation of business requirements with full knowledge of available IT
services and capabilities.

Specific Service Level Management (SLM) objectives may include:
• Establishing sound Business Relationship Management (BRM) between
service providers and customers
• Improving communication of IT services to the business and/or internal
customers
• Increasing the flexibility and responsiveness of IT service provision
• Balancing customer demands with the ongoing cost of IT service provision
• Measuring and reporting accurate service levels
• Implementing continuous improvement of IT service quality
• Ensuring objective conflict resolution

Specific Service Level Management (SLM) tasks should include:
• Creation of an IT Service Catalog
• Obtaining specific customer Service Level Requirements (SLRs)
• Establishing Service Level Agreements (SLAs)
• Establishing Operational Level Agreements (OLAs)
• Reviewing, creating and refining Underpinning Contracts (UCs)
• Implementing specific Service Quality Plans
• Monitoring, reviewing and reporting on IT service levels
• Establishing IT Service Improvement Programs (SIPs)
• Engaging the business through effective relationship management (BRM)

Minimum Requirements for a Service Agreement (SLA/OLA/UC):
• Timing / Period of Service Provision
• Service Description / Narrative
• Throughput (Inputs / Outputs / Service Levels)
• Service Availability
• Service [Desk] Response Times
• Sign-Off / Sponsorship (Physical Signatures)

Other Service Agreement coverage areas may include:
• Contingency arrangements
• Review procedures
• Change procedures
• Additional Support services
• Customer roles & responsibilities
• Administration requirements
• Maintenance requirements
• Amendments

Tip: Service Level Agreements must be monitored and reviewed regularly to
ensure IT products and services are being delivered optimally against all
service level requirements