applied eaf ngn deployment v1 - massey university · pdf filefinancial authorization,...

NOT TO BE DISTRIBUTED OUTSIDE Telecom/ALCATEL

Applied EAF: NGN Deployment of 81 Version 1.8 16 October 2003

Document No: ASG0007

Version Number and Status: Version 1.8 Publication Date: 16 October 2003

Review Date: April 2004 Type: Standard

Security Classification: Confidential Status: Approved

Enterprise Architecture Framework

Applied EAF

NGN Deployment

Error!

Approvers

Name Signature Date Stephen Crombie Murray Milner Greg Patchell

Use of This Document

This document is the copyright of Telecom Corporation of New Zealand Limited ("Telecom") and must not be disclosed or reproduced in whole or part without Telecom's prior written consent. This document is strictly confidential to Telecom, the EDS Telecom Account and the Alcatel Account Team as defined by the relevant contractual relationships and their non-disclosure requirements. Any changes modifications or updates should be requested via the Telecom Strategy Planning & Architecture group.



Revision History

Version Reason Reviser Date

1.8 First Approved Version MHJ 16 October 2003



Table of Contents 1 EXECUTIVE SUMMARY..................................................................................................................................... 5

1.1 WHAT IS THE APPLIED EAF? ............................................................................................................................. 5 1.2 HOW DOES THIS APPLIED EAF FIT WITH OTHER TELECOM INITIATIVES? ........................................................... 6 1.3 WHAT DO WE WISH FOR YOU TO DO WITH THE APPLIED EAF?........................................................................... 6

2 ARCHITECTURE WALKTHROUGH................................................................................................................ 7

2.1 HIGH LEVEL FUNCTIONAL DOMAINS ................................................................................................................. 7 2.2 EXPLODING THE HIGH LEVEL DOMAINS ............................................................................................................ 8 2.3 THE BIG PICTURE ............................................................................................................................................... 8 2.4 IP EDGE AND MPLS CORE ................................................................................................................................. 8 2.5 ATM AND DSL.................................................................................................................................................. 8 2.6 METRO ETHERNET AND BCL ............................................................................................................................. 8 2.7 PSTN, MOBILE AND TELECOM IDN/VPN.......................................................................................................... 8 2.8 NETWORK SESSION CONTROL ............................................................................................................................ 8 2.9 META DIRECTORY AND EAI .............................................................................................................................. 8 2.10 NGN VOICE CALLS............................................................................................................................................ 8 2.11 CONTENT AND APPLICATION SERVICES ............................................................................................................. 8 2.12 PRESENCE .......................................................................................................................................................... 8 2.13 EMPLOYEE AND PARTNER ACCESS..................................................................................................................... 8 2.14 CUSTOMER, PRODUCT AND INVENTORY DATA .................................................................................................. 8 2.15 CUSTOMER MANAGEMENT AND HISTORY.......................................................................................................... 8 2.16 CORRELATION OF ALARMS TO BUSINESS IMPACTS ............................................................................................ 8 2.17 PERFORMANCE MANAGEMENT AND TESTING .................................................................................................... 8 2.18 SERVICE ACTIVATION ........................................................................................................................................ 8 2.19 MEDIATION, RATING AND BILLING .................................................................................................................... 8 2.20 REAL-TIME FINANCIAL AUTHORISATION ............................................................................................................ 8 2.21 SECURITY ASSURANCE, INFRASTRUCTURE SERVICES & TECHNOLOGY MANAGEMENT ..................................... 8 2.22 SECURITY ZONES ............................................................................................................................................... 8

APPENDICES ................................................................................................................................................................. 8

AUDIENCE ...................................................................................................................................................................... 8 IMPORTANT NOTE: EXTERNAL REFERENCES ........................................................................................................... 8

APPENDIX A. IP ADDRESS MANAGEMENT......................................................................................................... 8

DESIGN RULES ............................................................................................................................................................... 8 ADDRESS ALLOCATION.................................................................................................................................................. 8 NOTES/GUIDELINES ....................................................................................................................................................... 8

APPENDIX B. SECURITY........................................................................................................................................... 8

DESIGN RULES ............................................................................................................................................................... 8 Rules for communication between layers .................................................................................................................. 8 Security in the Management Plane............................................................................................................................ 8 Security in the Routing Plane .................................................................................................................................... 8 Other Rules................................................................................................................................................................ 8

SECURITY NOTES/GUIDELINES....................................................................................................................................... 8 Guidelines on Anomaly Detection ............................................................................................................................. 8

REFERENCE MODEL FOR SECURITY ZONES .................................................................................................................... 8 Security Zones and Firewall Location ...................................................................................................................... 8

DESCRIPTIONS OF THE ZONES ......................................................................................................................................... 8

APPENDIX C. QOS (QUALITY OF SERVICE)........................................................................................................ 8

DESIGN RULES ............................................................................................................................................................... 8 NOTES/GUIDELINES ....................................................................................................................................................... 8 OPTIONS FOR SUPPORT OF MIXED DATA SERVICES ......................................................................................................... 8 NOTE ON QOS RELATED SEMANTICS: ............................................................................................................................. 8



APPENDIX D. EAI AND META DIRECTORY ........................................................................................................ 8

BACKGROUND................................................................................................................................................................ 8 DESIGN NOTES ............................................................................................................................................................... 8 NOTES/GUIDELINES ....................................................................................................................................................... 8

APPENDIX E. MEDIATION, FINANCIAL AUTHORIZATION, RATING AND BILLING .............................. 8

BACKGROUND................................................................................................................................................................ 8 DESIGN RULES ............................................................................................................................................................... 8 NOTES AND GUIDELINES (MEDIATION, FINANCIAL AUTHORIZATION, RATING AND BILLING) ....................................... 8

APPENDIX F. FULFIL ................................................................................................................................................. 8

DESIGN RULES ............................................................................................................................................................... 8 General...................................................................................................................................................................... 8 Inventory Systems...................................................................................................................................................... 8 Numbering Systems ................................................................................................................................................... 8

NOTES/GUIDELINES ....................................................................................................................................................... 8 NOTES ON RELATED HERITAGE SYSTEMS ...................................................................................................................... 8

FAIMS data migration............................................................................................................................................... 8 BUSINESS AND COMMON FUNCTIONS............................................................................................................................ 8 SEMANTICS NOTE .......................................................................................................................................................... 8

What is Operations Support and Readiness? ............................................................................................................ 8

APPENDIX G. ASSURE ............................................................................................................................................... 8

DESIGN RULES ............................................................................................................................................................... 8 NOTES/GUIDELINES ....................................................................................................................................................... 8 SEMANTICS NOTE. ......................................................................................................................................................... 8

APPENDIX H. OUTSTANDING ISSUES AND ACTIONS ...................................................................................... 8

OUTSTANDING ISSUES AND ACTIONS - ASSIGNED.......................................................................................................... 8 IP Address Management ........................................................................................................................................... 8 EDB, EAI, Meta Directory and AAA ......................................................................................................................... 8 Security...................................................................................................................................................................... 8 QOS........................................................................................................................................................................... 8 Assure........................................................................................................................................................................ 8 Financial authorization, mediation, rating and billing ............................................................................................. 8

OUTSTANDING ISSUES AND ACTIONS - UNASSIGNED ..................................................................................................... 8 IP Address Management ........................................................................................................................................... 8 EDB, EAI, Meta Directory and AAA ......................................................................................................................... 8 Security...................................................................................................................................................................... 8 QOS........................................................................................................................................................................... 8 Fulfil .......................................................................................................................................................................... 8 Assure........................................................................................................................................................................ 8 Financial authorization, mediation, rating and billing ............................................................................................. 8 Other ......................................................................................................................................................................... 8

APPENDIX I. DESCRIPTION OF BIG PICTURE FUNCTIONAL COMPONENTS ........................................... 8

APPENDIX J. GLOSSARY OF TERMS AND ABBREVIATIONS.......................................................................... 8



1 Executive Summary

Welcome to the Applied EAF for the NGN deployment.

This executive summary explains what the Applied EAF is, how it fits with other Telecom initiatives, and what we would like you to do with it.

It will appeal to those of us with a technical background, as it is primarily an architectural discussion. However, it presents a description of the overall NGN architecture that will suit a more general audience from senior management through to Solutions Architect levels.

The Appendixes are likely to appeal to a technical audience only, as they discuss detail of a specialist technical nature.

1.1 What is the Applied EAF?

The EAF was established with production of the High Level EAF model and its corresponding document. The audience is primarily at the General Manager level for Telecom and for a number of our Corporate Customers.

The Exploded EAF model and its corresponding documents elaborate upon the concepts that were introduced with the earlier High Level EAF. It as it this level that the document set becomes specialised, with titles such as “Unified Online Environment” and “Security and Profile Services” in which the High Level EAF is decomposed into manageable domains.

The Applied EAF further elaborates upon the Exploded EAF, and presents an initial view of a model and its description that result from “applying” the EAF to our NGN deployment aspiration. While the High Level EAF (level 1) and Exploded EAF (level 2) are generic across Telecom, the Applied EAF is specific to Telecom Corporation of New Zealand (Telecom).



1.2 How does this Applied EAF fit with other Telecom initiatives?

This version of the Applied EAF forms the basis of a “next phase” activity in which we continue to “apply” the EAF to the NGN deployment aspiration until we have produced a mature view.

This work will be driven by our Enterprise Architects, and will include a focus on using the overall EAF for the benefit of our Planners and Solutions Architects.

1.3 What do we wish for you to do with the Applied EAF?

Over time, the Applied EAF will mature, and this version of it will be absorbed (and possibly disappear).

Until this evolution is complete, the Applied EAF has value in five primary areas:

1. It provides a basis for decomposition of the NGN architecture into an integrated programme of work.

2. We can use it to strengthen our evaluation criteria for investment decisions, as the functional requirements for a number of system components are more clearly understood.

3. It can form the basis of a communications plan for informing our new and existing projects.

4. We can more effectively measure our NGN product and service aspirations against our ability to deliver.

5. We can better understand how we must evolve our operations business in response to deployment of an NGN service platform (the strong binding between the IS and Networks domains will drive change).

We ask that you use the Applied EAF for your purposes within your context as we together deliver the NGN service platform. Our team of Enterprise Architects will work with you to ensure that your specific needs are met as swiftly and efficiently as possible.

In time, be prepared to put aside this version of the Applied EAF, as its lifecycle within the overall EAF draws to a close.



2 Architecture Walkthrough

2.1 High Level Functional Domains

Before we begin walking through the Applied EAF for NGN Deployment, we will provide some initial context through examination of the High Level EAF and Exploded EAF as they relate to deployment of the NGN.

A key goal of the Applied EAF for NGN Deployment is to illustrate the “Big Picture” at a sufficient level of detail to provide useful architectural guidance at an implementation level. As a practical matter this means showing real functional blocks and the relationships between them. The resulting Big Picture is organised into the high-level functional domains shown in Figure 1, which correspond to the High Level EAF (the notable exception being “Operational Services” which are necessarily dispersed in our Big Picture in order to capture relevant relationships). This diagram is specific to Telecom Corporation of New Zealand.

Figure 1. High-Level Functional Domains

At the top of the diagram are the customer, partner and employee locations and devices. There is intersection between the network and the customer area because parts of the network are physically at customer locations (the customer located network equipment or CLNE).

All customer, partner and employee interactions with Telecom occur through the Consistent Customer Interface (CCI) while Telecom operates its Network through the Consistent Network Interface (CNI). Note that network in this sense includes not only ‘networking’ devices such as routers, switches and CLNE but also the servers, systems, databases and applications in the CCI, Integration Services and Core Business Function domains (the CNI touches all three of these domains as well as the Network Environment).

At the heart of the EAF is the Integration Services area which provides the glue between the CCI/CNI and the Core Business Functions which persist enterprise data and support the major operational business processes.

The reader is referred to the relevant EAF documentation for a description of each of these high-level domains.



2.2 Exploding the High Level Domains

As with the relationship of the High Level EAF to the Exploded EAF it is practical to further break this diagram one step before proceeding to the Applied EAF level of detail. This is illustrated in Figure 2, which provides an intermediate breakdown of the high-level functional domains.

Figure 2. Functional groups within the high-level domains

The primary purpose of this diagram is to provide the reader with a visual cue as to what types of functions reside in different parts of the Big Picture which follows in the next section. The reader is encouraged to spend a little time getting a sense of what’s where – but since the following pages walk through each area in some detail we won’t describe them quite yet.



2.3 The Big Picture

Now let’s jump in and see where we’re going to end up. The functional units and the major relationships between them are shown in Figure 3.

Figure 3. The Big Picture

Clearly this diagram is complex and requires explanation – which is the purpose of the following walkthrough. The following sections will walk the reader through a gradual build of this diagram describing key components and considerations along the way. This walkthrough is primarily intended to provide an overall context for the reader and does not attempt to provide a detailed explanation of each area.



2.4 IP Edge and MPLS Core

At the heart of the NGN is an MPLS Core fed by devices in the IP Edge. The MPLS Core is connected to other IP networks via connections between its IP Edge and the other networks’ IP Edge(s) as shown in Figure 4.

Figure 4. MPLS Core, IP Edge and Connection to Other Networks

Multi-Protocol Label Switching (MPLS) is an Internet Engineering Taskforce (IETF) standard for high speed switching that encapsulates an IP packet by adding a new header that contains a label used to define routing and differentiate between different classes of service. The MPLS Core will use MPLS routers which are set up to associate particular QoS attributes and traffic handling with particular labels. The MPLS Core therefore does not perform traffic separation or labelling; it simply ensures that traffic is handled correctly according to the label within the MPLS header.

Packets entering the MPLS Core must be correctly labelled which is the responsibility of the IP Edge. How the correct MPLS label gets applied will depend on how the traffic arrives at the IP Edge router and how the traffic is already marked.

The traffic may already be marked if downstream network equipment or applications have applied DiffServ marking to the IP packet header (unlike MPLS, DiffServ uses part of the existing IP header structure to indicate service type) or layer-2 marking. Mapping between DiffServ or layer-2 marking and MPLS is handled by the IP Edge.

Traffic that is not already marked will need to be separated and MPLS labelled at the IP Edge. An IP Edge router will apply an appropriate MPLS label to each packet and place it in a traffic queue appropriate to the quality of service required.

The functions performed in the IP Edge include:

• PE (Provider Edge) Routers. Maps customer traffic into appropriate MPLS virtual private networks (VPNs) – a process referred to as VPN injection.

• BRAS (Broadband Remote Access Server). Terminates ATM virtual circuits for DSL access and handles related PPP session establishment/teardown. PPP (Point to Point Protocol) is a means of establishing an authenticated IP connection – originally over a point to point link. It is the primary mechanism to establish IP sessions for dial-up Internet accounts via a RAS (Remote Access Server) and is similarly used to establish broadband connections (e.g. DSL) via a BRAS (Broadband RAS). Broadband variants of PPP are PPPoA (over ATM) and PPPoE (over Ethernet). NGN DSL access is detailed further overleaf in section 2.5.

• Firewalling (both general and voice specific). Limited high-performance general purpose Firewalling may be performed by devices in the IP Edge. However, the most significant requirement is for Voice-specific firewalls that provide control of the phone calls delivered over the NGN (for details see section 2.10 ‘NGN Voice Calls’).

• Policy Enforcement. Network policy (i.e. rules controlling network connections and traffic flows) is applied by the routers performing the BRAS and VPN injection functions.

• IP Interconnect. The IP Edge is the primary interface into other IP networks such as International, the Internet and external Internet Service Providers.



2.5 ATM and DSL

A key attribute of the NGN is the ability to deliver multi-service access, i.e. the ability for several different types of end device to share a single access line. The most common multi-service access scenario will involve an Integrated Access Device (IAD) at the customer location connected back over DSL and the ATM network to the IP Edge as shown in Figure 5. Note that the large arrows are used throughout this walkthrough to help highlight the part of the diagram being described – this becomes more important as the picture grows!

Figure 5. ATM and DSL

The ATM traffic management specification defines six service categories that have associated QoS attributes suitable for different traffic types.

• CBR Constant Bit Rate

• rt-VBR Real-Time Variable Bit Rate

• nrt-VBR Non-Real-Time Variable Bit Rate

• UBR Unspecified Bit Rate

• ABR Available Bit Rate

• GFR Guaranteed Frame Rate

An IAD has a combination of analog phone and ethernet ports. The ethernet ports might either be general purpose or function specific (e.g. a video port). The analog phone ports utilize a built in SIP Agent to enable voice over IP. The IAD therefore lends itself to the most basic form of traffic separation – port mapping. Figure 6 shows how different physical ports are mapped to particular ATM virtual circuits each configured with an appropriate ATM service category (e.g. rt-VBR for voice, UBR for other traffic).

Figure 6. Multiple Virtual Circuits

ATM Traffic Management

Specification Version 4.1 ftp.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf



It is noted that an alternative to having multiple virtual circuits would be to apply class of service marking using DiffServ at the IAD which enables the use of a single virtual circuit for all traffic as shown below.

Figure 7. Single Virtual Circuit

However, in the single VC model there is no differentiation between traffic types at the ATM level which renders this approach impractical at present due to the fact that ATM traffic management is the only practical mechanism available to guarantee the required Quality of Service (QoS) through the ATM aggregation network. For more detailed information on QoS the reader is referred to appendix C. Consequently, the NGN will use the multiple virtual circuit approach to delivering QoS for DSL access unless an exception is approved.

The ATM network will also support data-only DSL access via Conklin, Alcatel ASAMs and existing DSLAMs (like today’s Jetstream service) as shown in Figure 8.

Figure 8. DSL Access via Conklin



2.6 Metro Ethernet and BCL

Ethernet Access is typically used in metropolitan areas for connection of business customers. However, a special case of Ethernet Access is the BCL network which provides Ethernet Access over a wireless network for rural customers outside the DSL coverage area.

Figure 9. Metro Ethernet and BCL

Whether Metro Ethernet or BCL attached, the customer network is connected to the network by a router as shown in Figure 9. This router will be at the customer location but is part of the NGN network, hence the term “Customer Located Network Equipment” or CLNE. In nearly all cases, the customer network and customer premises router will not use MPLS, so MPLS can’t be used for labelling traffic to receive a particular QoS treatment at the network ingress. Instead the primary means of providing the right QoS will be via Ethernet’s layer-2 802.1p traffic class marking.

The Metro Ethernet network switches (e.g. Riverstone 38000) will handle traffic depending on the 802.1p traffic class marking for that packet. This means that the CLNE router must mark Ethernet packets with the correct 802.1p traffic class. This could be achieved in a number of ways:

• Traffic shaping (i.e. separation of traffic into different queues based on traffic examination) with appropriate 802.1p marking applied to the traffic from each queue.

• 802.1p traffic marking based on VPN membership (e.g. a voice VPN within the customer network receives a particular treatment).

• Remarking from DiffServ to 802.1p if downstream devices (e.g. end devices) support DiffServ. The use of DiffServ is expected to increase over time.



2.7 PSTN, Mobile and Telecom IDN/VPN

In addition to broadband multi-service access, the Telecom network will still include the PSTN and mobile CDMA networks which integrate with the NGN via the PSTN Gateway and PDSN respectively as shown in Figure 10.

Figure 10. PSTN, Mobile and Telecom IDN/VPN

Telecom employees and partners access data via either the Internal Data Network (IDN) or through Telecom virtual private networks (VPN). For the sake of articulating the architecture it is also useful to show these as a separate network, though in practice these utilize one of the other access networks such as ATM Access & Aggregation or Metro Ethernet.



2.8 Network Session Control

Many interactions over the NGN, whether it is making a phone call, surfing a web page or sending a message occurs within the context of a particular network session. The network session may persist for a short time or a very long time – for example, an IAD PPP over ATM (PPPoA) network session might last from the time it was turned on until something abnormal occurs – a power failure, network problem or an unpaid bill – possibly several years!

Figure 11. Network Session Control

There will be two dominant types of broadband network access – PPP (over ATM or over Ethernet) and Bridged Ethernet. In a Bridged Ethernet scenario, the network simply extends an Ethernet segment located at the customer premises back to the IP Edge so no PPP session establishment is required. In both cases one or more IP addresses must be allocated for the duration of the network session – usually dynamically allocated in real-time from a pool of addresses made available for that particular service.

The basic chronology for the establishment and management of a network session is as follows:

1. In the case of PPP the BRAS in the IP Edge sends a RADIUS request to the RADIUS Proxy which forwards the request either to an external RADIUS Server (e.g. in the case of wholesale DSL) or to the Telecom primary RADIUS Server. The Alcatel SMC product is used to provide both the RADIUS Proxy and RADIUS Server functions.

2. The RADIUS Server is synchronized with the Master Directory (Novell e-Directory) which is the master repository of authentication and authorisation information. This synchronization occurs by means of a connector with appropriate attribute translation defined by business logic in the Meta Directory (Novell e-Directory).

3. Assuming successful authorisation, an IP address is allocated to the network connection by the real-time IP address allocation system (Alcatel SMC) and information about the network session state including the IP address and virtual circuit identifier is stored in the Session State Server (Alcatel Session Master for network sessions).

4. On successful establishment of the session and allocation of the IP address the IP Edge will apply a Policy persisted in the Policy Server based on the user profile in the Master Directory. The Policy Server and Master Directory will be tightly coupled so that if there is a Policy related change in the customer profile in the Master



Directory the Policy Server will cause a new Policy to be applied at the IP Edge. For example, if exceeding a Megabyte (MB) limit triggered a change to the profile in the Master Directory, the Policy Server might cause a restricted use Policy to be applied to that network session.



Sidebar: Network Session and User Identity

With PPP over Ethernet (PPPoE) there may at first appear to be a natural association between user and IP address at the RADIUS Server. However, this association can be quite weak in practice since it is common for multiple people to use the same PPPoE username/password combination. For example in setting up a PPPoE connection in Windows XP the user is specifically given the option to “use this account name and password when anyone connects to the Internet from this computer” if the connection is set up for “anyone’s use” (see screenshots below). Even using “me only” settings instead has little impact for most homes and many small business situations because users typically share the same Windows XP login (it is simply not convenient to log out and back in).

��

It is a key Telecom objective to identify the actual user associated with a particular session rather than just the bill-payer. Clearly this is not achieved in the network authentication process with either DHCP or PPPoE. While this may never be achieved with some services (such as residential telephone), for most next-generation services the opportunity exists to separately identify a user. For example, this may be achieved in one of two ways for PC-based users:

• Force redirection of all http connections to a “captive portal” until after the user logs in. When the user logs in a relationship between the user and a cookie identifier is persisted in the Session State Server.

• Let the first application requiring identity initiate identification of the user, and store that information in the Session State Server (this is discussed in more detail under “Content and Application Services” in section 2.11).



2.9 Meta Directory and EAI

Telecom has over 250 primary systems. Historically these systems have each implemented their own identity, authentication and authorisation mechanisms and connections between systems have been implemented on a point-to-point basis. The resulting complexity is unsustainable in terms of both cost and responsiveness (e.g. ICMS alone has over 100 separate connections to other applications and changes can take several months).

The Meta Directory and EAI are strategic initiatives that address this problem.

The EAI (Enterprise Application Integration) uses the Crossworlds toolset to externalize reusable functions and thus enable a hub-and-spoke application architecture with EAI at the hub. The EAI also provides workflow and synchronization tools so that information is persisted in the necessary target systems.

Meta Directory uses the Novell e-Directory product suite to provide a set of directory-style interfaces (LDAP, RADIUS, SOAP etc) into the customer profile information mastered in the customer database (an instance of Oracle 11i running the TCA schema) as well as synchronization with other operational slave directories. The reader is referred to the EAF Security and Profile Services publication for detailed information.

Meta Directory is therefore the primary interface between the network/systems authentication and authorisation environment and the EAI environment as shown in Figure 12. It is also the point of connection to a Public Key Infrastructure (PKI) which would be used for stronger, crypto-based authentication of users or devices.

Figure 12. Meta Directory and EAI

One area of potential confusion is that the term Meta Directory is often used to refer to Telecom’s instance of Novell e-Directory. In fact, the role of Meta Directory (i.e. a repository of meta information about other directories) is only one of the functions performed by e-Directory. Equally important is the role of Master Directory – which is the master repository of authentication and authorisation information in Telecom.



2.10 NGN Voice Calls

The key components in a wireline voice call on the NGN are the SoftSwitch, Resource Broker and Voice Firewalls as shown in Figure 13.

Figure 13. NGN Voice Calls

The process of call establishment is as follows:

1. When the handset is lifted a SIP Agent in the IAD sends a SIP Invite message to the SoftSwitch (e.g. the Alcatel 5020) requesting establishment of a call to a particular party.

2. The SoftSwitch asks the Resource Broker (the Alcatel Session Resource Broker) whether there is sufficient network resource available for the call to be connected while guaranteeing the required service quality.

3. If the call can proceed then the Resource Broker instructs the Voice Firewalls (Alcatel Access Border Gateway or ABG, formerly known as Aravox) to open a ‘pinhole’ in the network so that the call may proceed. The SoftSwitch then responds to the SIP Invite with a message for the call to proceed.

The long-term vision for the network is that the Resource Broker is an application that has a multi-service view of demands on the network so that, for example, a video call does not commence if the phone traffic already on the network would prevent delivery of the required QoS. The practical initial tools for dynamic resource allocation consist primarily of Policy Servers and limited resource-broking (e.g. opening pinholes). This means that over-provisioning of network bandwidth will be required initially to deliver required QoS for some applications. Over time additional resource-broking functions will be introduced so that the resource-broker has broader awareness of the network (e.g. the ATM/DSL access) so that the need for over-provisioning is reduced.



2.11 Content and Application Services

A Consistent Customer Interface is a key architectural goal (refer the EAF Unified Online Environment publication for detailed information). This means that any access to an online capability service – whether it is a self contained content service, a self-service interface for administration of a communications service, access to web-mail, or performance/SLA reporting – should occur through a common interface environment as shown in Figure 14. This implies that pre-Packaged direct web interfaces to Application Servers should not be exposed to users.

Figure 14. Content and Application Services

The process by which authenticated access to an Application Server should occur is as follows:

1. The user types a URL into their browser which is resolved to an IP address via a Domain Name Server (DNS). The Application Server with this IP address refers a device or network session identifier (e.g. a cookie) to the Session State Server to determine whether there is a current and valid user session associated with the device/network session identifier.

2. Assuming the user is not already identified, the Session State Server will respond, indicating that a user session has not been established, in which case the Application Server will use the Sign-on Server to identify and authenticate the user (or actually redirect the session to a Sign-on server). The Sign-on Server will authenticate the user based on the authentication information stored in the Master Directory and will update the Session State Server so that the person does not have to re-authenticate when using another content service in the time context of the established session.

3. The Application Server will now obtain any authorisation or personalization information required directly from the Master Directory.

It is noted that while there is a single functional box for Session State Server it is unlikely that a suitable combined network/application Session State Server is available off the shelf. A possible strategy is to extend the Alcatel Session Master to support application session state, but further work is required to scope this correctly. Another consideration for this work is that the mobile-driven Parlay standards provide certain session/state services to any querying entity over open APIs.



2.12 Presence

Presence is an important strategic consideration because over time it becomes a key mechanism to initiate next generation services and is a key technology for the integration of wire-line and mobile technologies. If the reader is unfamiliar with Presence and its strategic significance then the following sidebars may provide some context.

Sidebar: What is Presence?

Presence means making a user’s state information available to other users who have permission to view it – often manifested as a buddy-list. Common consumer examples of Presence applications today include instant messaging (e.g. MSN, AOL instant messaging and ICQ which the IETF is attempting to bring together via CPIM) and games communities as shown in the screenshots in this sidebar.

A business example of Presence would be the ability to automatically indicate state (e.g. “out of the office”, “in a meeting” etc) to callers. Such a capability might be tightly integrated with Outlook and might be delivered via a Telecom service like IP Centrex.

Presence Today:

Examples include MSN Messenger (above) and Zone.com (left)



Sidebar: Presence and Service Initiation

Both the MSN instant messaging example and games community server examples above demonstrate Presence-based service initiation (you click on a buddy or player and initiate either an instant message dialogue or a game).

However, Presence is increasingly being used to launch more traditional Telecommunications services. For example, until recently NetMeeting was Microsoft’s primary application for establishing video calls, voice calls and collaboration over the Internet. The mechanism by which you found other users was via a public or corporate directory (often also operated by Microsoft). However, if you launch the latest version of NetMeeting and click on the phone-book icon to locate another user, instead of opening the Microsoft Internet Directory you will see the message in window 3 above (“The Microsoft Internet Directory service has been superseded by features now provided with MSN Messenger”).

Under Windows 2000 NetMeeting was available by default in the “Programs” section of the Windows “Start” menu under “Accessories”. That is no longer the case in Windows XP (it is still there but you have to type conf.exe at the command prompt to launch it!). That’s because Microsoft wants users to use Messenger – its Presence-based service. As seen below, Messenger is now Microsoft’s preferred mechanism for users to initiate phone calls, video calls and other communications.

Service Initiation:

The NetMeeting Directory service (above) has been superseded by MSN Messenger (left) as Microsoft’s preferred mechanism for initiation of all call types including voice and video.



Sidebar: Presence and Mobile

One thing that software firms can’t offer (without the partnership of a Telco) is integration of mobile capabilities into a Presence based service. And Presence has particularly interesting implications in the mobile environment. A straightforward mobile integration Presence requirement would be a service that allows a user to automatically indicate to colleagues or buddies the fact that they are currently on the mobile phone (so calling parties know they’ll get voice-mail and might elect to send an instant message instead). By integrating that capability with Presence capabilities related to wireline voice Telecom could offer a compelling new capability that would leverage its integrated multi-network capabilities.

As mobile phone services advance, the need for Presence capabilities will increase. For example, consider push-to-talk services in which the mobile phone emulates a walkie-talkie (such a service offered by Nextel www.nextel.com has already proved popular in the US). This means that your mobile service acts much like instant messaging – rather than dial another user you would simply select their name, push a button to talk, and start talking (“Hey Bob, it’s Bill you there?”). Obviously this relies on a relatively high speed always-on mobile capability. However, for this type of service to be useful in a business setting you need to know in advance if the person doesn’t want to receive calls – which is a Presence function.

From an architectural perspective the Presence Server must sit between the Meta Directory (which contains the profile information on which buddies a person wishes to monitor) and the Session State Server (which updates the state of those buddies). This is illustrated in Figure 15. The architectural implications are significant: To deliver the strategic advantage of an integrated Presence capability it is necessary to have an integrated Session State Server (which can provide state information across several service types) and a single Master Directory.

Figure 15. Presence



2.13 Employee and Partner Access

In general terms, employees and partners access support systems through the same Consistent Customer Interface architecture as other customers. Two specific examples – customer service representative (CSR) access to customer management and service company workforce management integration are illustrated in Figure 16.

Figure 16. Employee and Partner Access

CSRs access Order Entry, Inquiry and other Customer Management facilities via the Consistent Customer Interface. As such, it share the common Sign-on and authorisation mechanisms but has a purpose specific Application Server – GTX from Graham Technologies – which provides rapid development of applications to leverage core business functions and network integration capabilities exposed via the EAI.

The integration of service companies’ Workforce Management systems with Telecom’s own Workforce Management system illustrates another important component of the customer interface – the XML Gateway. The XML Gateway exposes EAI functions to the outside world via XML and SOAP. The functions available via the XML Gateway are advertised and documented via the UDDI which over time Telecom will also use for the purposes of advertising system capabilities internally. The list of functions available to an external system with a particular set of credentials is naturally mastered in the Master Directory.

This also illustrates the mechanism by which a third party partner (including application developers) will access the Telecom network. It is also noted that UDDI and the related Web Services Description Language (WSDL) are part of the Parlay X specifications.



2.14 Customer, Product and Inventory Data

The concepts of product, Logical Inventory and Physical Inventory are not as simple as they may appear on the surface. This is an area where semantics are particularly important, especially with respect to products, because there is significant potential for confusion as to which systems are responsible for what. The primary systems associated with Product and Inventory Data are shown in Figure 17.

Figure 17. Customer, Product and Inventory Data

Product is a generic term for the products and services actually marketed and sold to the customers of Telecom. A Product is a member of the Product Catalogue which is the repository of the set of products Telecom sells along with their sales rules, pricing plans and so forth. Products are either Product Items (the simplest level of a product that Telecom sells) or Packages of Product Items (Packages are a collection of Product Items sold as a single product).

Significant complexity exists because there is not a simple direct relationship between Product Items and the elements that go into delivering and managing that Product Item. A further level of abstraction is required – Product Components are the things and actions that make up a Product Item for the purposes of provisioning (e.g. send out brochure, activate network item X, and initiate billing). A subset of Product Components is network items – those network, system and application elements that are provisioned in the network by the Service Provisioning system (see later).

The inventory of available network items from which Product Items can be provisioned is mastered in the Logical Inventory. By contrast, the Physical Inventory is the master of physical installed plant information and associated GIS information – such as fibre, copper and rack-mounted equipment.

However, the Logical Inventory will include not only non-physical resources such as numbers, names, configuration, virtual circuits and VPN information – but also those physical items that are a necessary network component of a



Product Item (such as a copper access line). In other words, Logical Inventory must include a logical view of all network resources including the physical so that products can be defined solely in terms of Logical Inventory. There is therefore naturally some overlap between Logical Inventory and Physical Inventory – and where such overlap occurs Physical Inventory is the master repository, but the interface to Service Provisioning, Product Item etc should be through Logical Inventory.

One special aspect of Logical Inventory is VPN Management. At an architectural level it is considered desirable that the Logical Inventory solution would include VPN Management, but there are many functions that are VPN specific and a separate VPN Management solution may be warranted. This requires further investigation.

Target systems for Inventory are as follows:

1. Physical plant: NetMAP.

2. Physical RME (Rack Mounted Equipment): unresolved.

3. CLNE (stock): unresolved.

4. Logical: AXiOSS IMS.

5. VPN and configurations: AXiOSS IMS - subject to confirmation of suitability.

6. Financial asset management of CLNE - SAP subject to confirmation.

The Customer database masters information about customer parties (i.e. organisations, individuals, groups) and addresses and relationships between them plus links to account, credit worthiness, and profile information.

The Contracts and SLAs system maintains the relationship between customer/account and Contracts/SLAs.

Installed Base records the list of products sold to a customer along with the associated Product Items and product attributes. Like Customer, Contracts and SLAs and Product, Installed Base information is mastered in Oracle 11i. However, it is important to note that Installed Base is not the whole story in terms of “what a customer has”. Installed Base only contains the information as to what products (i.e. Packages and Product Items) are associated with a particular customer. The relationship between what Logical Inventory (i.e. network items) is associated with a particular customer is persisted in the Service Provisioning system (see later).



2.15 Customer Management and History

As already described, CSRs use systems in the Telecom environment via the Consistent Customer Interface. However, the actual data and process support systems that they need for handling new orders and customer enquiries are core business functions connected to the EAI as shown in Figure 18.

Figure 18. Customer Management and History

When a customer wants to place a new Order the Product Configurator executes sales rules to find a suitable Product and collect configuration information from the customer to populate Product attributes. It is responsible for creation and modification of Quotes, Orders, Contract/SLA and (among other systems) updates the contact history which maintains the record of customer interactions. It also invokes order feasibility which determines the technical feasibility of delivering a particular service to a customer (e.g. are they in the coverage area).

If the customer wishes to proceed with the Order and this is approved by the Credit Check system then Order Management accepts and schedules the Order. It breaks the Order into components, requests fulfilment, requests charging to be established, updates the Installed Base and manages Order fallout and escalation. It utilises Workflow to implement the processes defined for each Product action combination. Workflow is a system shared by many processes for the coordination of business-level process steps (as distinct from use of the term ‘workflow’ to refer to the coordinated update of multiple systems at the integration services level – this use of the term workflow is to be avoided).

Finally, all of this customer interaction information along with information about the use of Products is stored in the Data Warehouse to facilitate analysis and development of future product and marketing strategies and campaigns. There are also service creation, campaign management and other product/marketing support systems that are not shown in the diagram.



2.16 Correlation of Alarms to Business Impacts

A common feature of proposed NGN services is the need for strong correlation between network events and customers, services and service-level commitments. Hence the “Alarm Management” chain no longer terminates at a network “Manager of Managers” (i.e. Event Correlation system) but instead continues all the way into the EAI via the Business Correlation system shown in Figure 19.

Figure 19. Correlation of Alarms to Business Impacts

Element and Domain Managers are management sub-systems associated with specific network equipment that provide isolation from the proprietary interfaces on the equipment and provide engineering interfaces to the equipment. There are several Alarm Converters which convert Element/Domain Manager alarms to the (usually proprietary) internal format used by the Event Correlation system. The Event Correlation system filters and groups alarms so that it passes on only significant network events which the Business Correlation system then compares with customer, product and SLA data. A normalized data structure in the Business Correlation system can significantly reduce the overhead required to establish the relationships between significant network events and business entities.

The Business Correlation system identifies significant business events, but it is the Workflow system that coordinates any pre-planned response – including updating other systems such as SLA Management, Problem Management (which handles both detected and reported problems) and Billing (for SLA rebates).

It is emphasized that we use the term “Network” to refer not only to the network hardware and transmission capability but also to all the systems and applications that form part of the Network. This is of particular relevance with respect to Assurance – there should only be one alarm correlation chain for network, systems, database and applications. Similarly, the functional unit “Element & Domain Managers” should be in place not only for traditional networking equipment but for other entities requiring management – servers, systems, databases and applications.



2.17 Performance Management and Testing

Apart from the alarm correlation chain just described, the other significant components related to the Assure process are performance management and testing systems as shown in Figure 20.

Figure 20. Performance Management and Testing

The Performance Aggregation system collects performance statistics for network, applications, systems, databases and processes – usually from Element/Domain managers – and contains rules for performance summarisation and roll up. It persists performance thresholds and based on those thresholds generates performance alarms to Event Correlation. It is the primary source of accounting data (refer Section 2.19 on Mediation, Rating and Billing).

While the Performance Aggregation system might itself have the ability to generate performance reports for Telecom/Alcatel Operations staff, widely used reports (such as customer self service SLA reports) would be handled by a Reporting Application Server that is tightly coupled with the other components of the CCI.

Similarly, while Telecom/Alcatel Operations staff may conduct certain types of testing directly or using dedicated systems, if testing functionality needs to be exposed to the end customer or a CSR then such test functions will be exposed through a single Test system that is attached to the EAI.



2.18 Service Activation

The process of configuring network components is handled by the Service Provisioning system (AXiOSS 02S) which is obviously tightly coupled with the Logical Inventory system (AXiOSS IMS). The Service Provisioning system handles workflow sequences for network provisioning processes and decomposition of components/network services into logical network capabilities. It allocates network resources (including network, server, system and application resources) from Logical Inventory and Physical Inventory and configures and activates those network resources – including writing profile information to Meta Directory where this is a required provisioning step. It directly connects with Element/Domain managers and other systems as shown in Figure 21.

Figure 21. Service Activation

There is a single Service Provisioning system for all services. So in addition to provisioning NGN services via the Element and Domain Managers, Service Provisioning will also provision PSTN services via PSTN NAS (the existing PSTN Network Activation System).

The Number Translation system is a real time source for the association between dialled number, routing digits and location for the NGN. These relationships are provisioned into Number Translation by Service Provisioning based on the numbering master in Logical Inventory (AXiOSS IMS). The same is true for IP Address Ranges which are provisioned into the real-time address allocation system (Alcatel SMC) by Service Provisioning from the addresss (and address ranges) mastered in Logical Inventory (AXiOSS IMS).



Sidebar: Customer Self Service It is an architectural goal that a majority of functions performed by a CSR on behalf of customers (e.g. provisioning of services, testing, performance reporting and billing) can also be achieved by the customer themselves through a customer self-service portal. This is supported by the architecture by means of common capabilities exposed through the EAI – there is no difference to back end systems whether the capability is called on by the GTX CSR Interface or the TEX self-service portal (i.e. telecom.co.nz and xtra.co.nz web sites) or other parts of the Consistent Customer Interface (such as a mobile phone interface).



2.19 Mediation, Rating and Billing

With the notable exception of mobile prepay, for most services today mediation, rating and billing occur after the billable event itself occurs. The systems involved in such post-event mediation, rating and billing are shown in Figure 22 (prepay and real-time financial authorisation are discussed in section 2.20 next).

Figure 22. Mediation, Rating and Billing

The Mediation system (the Intermediate product) gathers accounting records from several sources including the SoftSwitch, PSTN gateway and IP Centrex server (for IP Telephony Call Detail Records – CDRs), the RADIUS Server (for RADIUS Accounting Records), the AMA Collector (PSTN phone CDRs in CDUP format) and the Session State Server (for content and other application level billing events). It is noted that no distinction is made between RADIUS authentication/authorisation servers and RADIUS accounting servers (i.e. one server may perform all roles).

Where usage information needs to be directly obtained from network elements or Element/Domain managers (i.e. other suitable usage records such as RADIUS accounting records or CDRs are not available) this information will be fed to the Mediation system via the Performance Management system.

In addition to collecting accounting records, the Mediation system also correlates and reformats usage information for subsequent pricing by the Rating system (the Convergent Biller product from SingleView). The Rating system is also the master of product price information including special price events, one off product pricing, subscriptions and discounts.

Bill presentation will continue to be performed by ICMS for some time.



2.20 Real-time financial authorisation

Where financial authorisation is required rapidly (i.e. less than 100ms) prior to service delivery commencing then this authorisation is performed by the Real-time Financial Authorisation system (the Commerce Engine product). The primary initial application of Real-time Financial Authorisation is for mobile prepay via the mobile Universal Application Server (UAS) as shown in Figure 23.

Figure 23. Real-time financial authorisation

The Real-time Financial Authorisation system provides rapid (<100msecs) authorisation of network transactions from a pre-paid account. It maintains a current account balance and generates tokens that are passed to the service control point (the UAS in the case of mobile). These tokens are based on the value of service being requested and indicate to the service control point how long service may be provided for before additional financial authorisation is required.

The Real-time Financial Authorisation system also performs its own mediation. Thus prepay and real-time authorised events are not meditated by the Mediation system (except in certain failure situations).

In the case of mobile, real-time authorisation is required not only for mobile voice calls but also for WAP and PDSN based services – which requires the UAS to interact with the RADIUS Server.



2.21 Security Assurance, Infrastructure Services & Technology Management

Finally, there are three additional areas that complete the Big Picture – security assurance, technology management and infrastructure services. The Security Assurance and Technology Management functions are shown in Figure 24.

Figure 24. Security Assurance and Technology Management

Security Assurance (top right arrow) includes Audit (keeping track of who did what), Vulnerability Monitoring (making sure all the doors and windows are closed) and Anomaly Detection (the burglar alarm). Together with the Public Key Infrastructure and the profile related systems in the CCI and Network these systems comprise the Security and Profile Services bar of the EAI – effectively an overlay that encompasses all the different layers of the model.

Technology Management (bottom right arrow) refers to the systems that are dedicated purely to the operational readiness and support of Telecom’s technology environment. It is noted that many systems usually associated with Technology Management (such as problem management, performance management and so forth) are already part of Telecom’s main operating environment – it is not intended that separate management systems be constructed dedicated to Telecom’s own systems.

It is noted that there is a small number of critical systems whose sole purpose is to provide supporting services to the other systems in the environment. These systems, which include Network Time and Internal DNS (not shown on the diagram) are referred to as Infrastructure Services.

Finally, we have included two last components to the Big Picture in the Figure 24 iteration – Translation Services and High Availability and Throughput Services. The first recognises a target goal in which presentation is truly abstracted from content and application services via a translation layer (i.e. XSLT being applied to XML data) while the second recognises that significant infrastructure investment is required to achieve the organisation’s performance and availability goals.



2.22 Security Zones

The EAF overlay introduced at the start of the Architecture Walkthrough (section 2) is not the only useful overlay that can be applied to the Big Picture. Figure 25 shows how the diagram can be split into security zones – trusted at the bottom, untrusted at the top, and appropriately colour coded.

These security zones are used to define security rules for issues like firewall location, which zones can talk to what other zones and so forth. These security considerations are detailed in appendix B.

Figure 25. Security Zones

It should also be noted that this framework illustrates the minimum separation required. Additional sub zones may be created as required to deal with different levels of trust within a zone. For example additional separation will be provided around the BCL access network within the Access and Aggregation layer..



Appendices

Audience

The following appendices present information of a specific technical nature. They are intended for staff directly involved in the deployment of NGN technologies. They assume a sound knowledge of IP networking and related terminology.

IMPORTANT NOTE: External References

Each appendix deals with a particular subject matter area. We have attempted to provide concise and precise guidance in each area with respect to NGN deployment. However, in certain areas there are existing detailed EAF publications that provide greater detail and should be regarded as the point of reference for detailed design purposes. At the time of writing this note specifically applies to the following appendices:

Appendix B. Security. Refer EAF Publication “Security and Profile Services”

Appendix D. EAI and Meta Directory. Refer relevant EAF Publications.

Other References that readers should be familiar with include:

Next Generation Network, Level 1 Submission, Reference Architecture, Edition 3 Release 2, July 2003.

Enterprise Architecture Framework & Overview, Version 2.0, February 2003.



Appendix A. IP Address Management

Design Rules 1. Telecom must achieve a public IP address space utilization of greater than 80% (Telecom must be able to

demonstrate such utilization in order to obtain further allocation of public IP addresses). 2. Telecom will not use IPv6 before 2005. 3. NAPT will be used wherever practical, to maximize utilization of public address space. 4. Voice+, PSTN Replacement, Mobile, Set-top Video will use the 10/8 Private Address Space. If Internet access

is required from end-devices, NAPT will be performed at the boundary between the NGN and the Internet. 5. Data Services inherently requiring a public IP address (i.e. providing Internet access as a primary function) must

use NAPT at the CLNE wherever practical except that: a. Though it is preferred that customers use private addresses on their side of the CLNE, the CLNE must

also allow customers to use public addresses for end-devices. b. Where a DHCP server is provided by CLNE for private address allocation, the CLNE must support the

ability for customers to adjust the private DHCP scope (Note: the ability for customers to adjust NAPT or DHCP scope settings should not compromise security rules. For example, customers should not be able to configure the CLNE through an uncontrolled connection to the device).

c. Where a Data Service has a need for Telecom allocated private address space (e.g. Friendly Garden servers, VPNs with Telecom allocated IP addresses, consumer DHCP scope) 10/8 will be used.

6. Infrastructure. All network equipment except CLNE will be assigned public IP addresses. 7. NAPT must be used between VPNs where there is any potential for IP address space overlap. For example, CNLE

ALGs may introduce potential for IP address space overlap with corporate VPNs. 8. The Telecom national NGN network will use a single ASN. 9. IP address should not be used as a primary user identity mechanism. 10. Allocations of both public AND private IP addresses will be handled by a single Telecom-wide IP address

Registry. The Registry will be responsible for ensuring that all reporting requirements are met. 11. The Registry will be managed by Alan Fagan. All requests for new public or private IP address range allocations

should be directed to him ([email protected] ). Where necessary, he will coordinate with Don Kendrick (Advanced Solutions) regarding public IP address range allocation.

Address Allocation The primary 10/8 private address ranges allocated to applications are shown below. There will be an NAPT connection to the IDN and other existing private address spaces. The Registry is responsible for allocation of sub-ranges within these primary ranges. It is expected that sub-ranges will be largely geography-based. Development, Staging and Test environments should also use sub-ranges within each primary range (i.e. they will be treated much like a separate geographic area).

Application Range Allocated Reserved 10.0/11 Voice 10.32/11 Mobile 10.64/11 TV 10.96/11 Data Services 10.128/11 Mgmt 10.160/11 Reserved 10.192/11, 10.224/11

Notes/Guidelines IADs will need to support several virtual circuits (e.g. Voice, Data, Video, and Management). Game Consoles. There will be 300-500,000 networked game consoles. They are likely to use IPv6 through PPPoE tunnels terminating at Sony/Microsoft. IPv4 is expected to continue in use for 10 years (in parallel with IPv6 after 2005). It is desirable that CLNE use a separate VC/VLAN and private IP address space for management. CDMA will not require significant IP address space in the medium term due to air interface limitations. UMTS is expected to use IPv6.



Appendix B. Security

Design Rules Read these design rules in conjunction with the diagram and table later in this appendix which describe the different security zones and layers.

Rules for communication between layers 1. Devices only communicate with layers that are adjacent from an IP perspective. (The access and aggregation

layers are typically Layer 2 technologies and only implement IP for control and management functions. They do not participate in service flows at the IP layer.)

2. Devices in the customer zone only use IP to communicate to the following other zones: • to service edge for access to services • to IP edge for routing updates • to customer management zone of management plane for element management

3. There will be no direct communication with the control plane. Communication will be via an intermediate layer e.g. service edge or access/aggregation.(note: it is possible that access to the control plane will be required in certain circumstances but this will only be as a specific exemption with appropriate associated security measures).

4. Devices in the service edge only communicate to control/middleware layer(s), customer layer, and IP edge. 5. Devices in the control/middleware communicate only to the systems layer and Services edge layer. 6. Everything can talk to management plane but must do so via firewalls.

Security in the Management Plane 1. Must support roles / skills based access rights to management systems and network elements e.g. Role base

access to routers is required (i.e. multiple levels of access). 2. Should use Radius based access controls as default for network elements. 3. Servers use native centralised authentication but it should be integrated into MetaDirectory. 4. Customers must not have direct access to management of their own CLNE (i.e. any customer control of

configurations must be via the service edge). Otherwise same principles as other n/w nodes apply. 5. Security management should be isolated from the rest of management layer. 6. Use encryption of passwords (or other secure authentication) in all cases, where sniffing is a risk encrypt all

management traffic unless it is not supported by the NE. 7. Migrate all services to CHAP (from PAP) so that passwords are not sent in the clear. This should be a

significant consideration for the selection of CLNE.

Security in the Routing Plane 1. Use MD5 between routers (simpler to make this a universal rule). 2. Always manage any CE that sends routing updates and always use MD5. Never accept routing updates from

unmanaged CE that doesn't have MD5. 3. Traffic to external networks and the internet also requires authentication etc. MD5 is recommended as a

starting point for consideration.

Other Rules 1. Vulnerability monitoring is required:

• network based vulnerability monitoring should be implemented as a priority i.e. probes in each plane looking at all servers in plane and validate accessibility of neighbour planes.

• server based: lower priority and harder to implement. 2. All PKI will be done via MetaDirectory. 3. All boxes need to be hardened: (i.e. only enable functions / ports that are required for its function in the

network). This implies a level of standardisation.



Security Notes/Guidelines 1. It is recommended that IP address management and Security-related documents be handled & distributed with

tighter controls than other architectural documents.

2. Because peering can occur at any layer up to and including the control plane, Telecom's security layers will not align with an external network, and we can't trust their layers - therefore we should design appropriate security barriers on a case by case basis.

3. It is recommended that virtualisation of firewalls occurs via layer 2 or lower separation of ingress and egress

traffic (e.g. VLANs, VCs) as it is less prone to error than the use of IP address range segregation (which is what is used in the current incarnation of the SBI service).

4. It is recommended that the Management plane uses out of band connections to the network element to increase

the resilience of the overall management solution including the security aspects. Physical separation is preferred over logical (i.e. L2) separation.

5. Note that this framework illustrates the minimum separation required. Additional sub zones may be created as

required to deal with different levels of trust within a zone. For example middleware may be separated from control plane where a system is untrusted or has separate organisational management or has extensive connectivity. However, a single partition is the general rule with additional security partitions as required.

Guidelines on Anomaly Detection 1. Should have anomaly detection capability. This will most likely be in the service edge and may be targeted to

specific applications rather than universal. It may also be required in other layers.

2. Log collection and analysis in service, control and systems layers should be a minimum.

3. All boxes should have alerts based on anomalous thresholds (e.g. unusual resource usage levels).

4. Anomaly detection should not normally be in line because it can add delay and is a potential point of service failure.

5. Responses to anomaly detection should not normally be automated.



Reference Model for Security Zones

Security Zones and Firewall Location

The diagram below and the following table describe the security zones that are to be deployed.



Descriptions of the zones

Zones Layers / sub zones

Description

Network Zones

Customer Locations Any devices in the customer's premises including CLNE. Equipment in the customer premises are never trusted and are always at risk of tampering.

Access & Aggregation The layer 2 network that provides connections between customer sites and the IP edge. These access and aggregation elements also include L3 agents for control and management purposes and so can also be L3 end points and/or L3 routers. Security concerns relate to L2 on the customer side and L3 on the management and control side.

IP Edge and Core The IP traffic infrastructure that is shared by customers. That is, the elements that carry customer traffic and switch it at L3 and above between IP end points. The IP edge does not terminate customer IP traffic but it will terminate L2 and below circuits (e.g. VCs, VLANs, PPP tunnels etc).

Service Edge The IP device that terminates customer IP traffic and delivers network hosted services (e.g. content and service logic). Equivalent to the Consistent Customer Interface layer of the EAF.

Control Plane & Middleware

This layer has two functions. First it provides real time (i.e. session based) control functions to the network such as serving up session profiles, identity management, admission control etc. Second it provides middleware services to map service edge to content services.

System Plane Predominantly a combination of the EAF Core Business Systems layer and Integration Services layers of the EAF. Also includes Mediation, Financial Authorisation, Directories, Business Correlation and Performance Aggregation.

Trusted reusable business objects and systems.

Development and Testing A separate development and testing environment needs to exist to develop and test hardware, software and service designs before they are released into the live network. This environment must be securely isolated from the rest of the network as it will always be less trusted than the live network.

Management Plane Element management and communication with the network elements

Customer Management Plane

Customer devices require additional isolation from the rest of the management plane because of the inherent lack of trustworthiness of elements in customer premises.

Network Management Plane

The rest of the management plane.

Infrastructure Common systems that are used by systems (but not end device) in the Services edge, control, and system planes (e.g. DNS, NTP servers etc that non customer devices need).

External Any connection to a non Telecom network apart from customer networks connected via CLNE.



Appendix C. QoS (Quality of Service)

Design Rules 1. The Core will be statistically provisioned for at least the next 18 months. Traffic engineering will be at the

aggregate level, not session by session. There will be analysis of traffic and network level configuration based on traffic reviewed periodically (of the order of months).

2. Multiple VCs (or VLANs) will be used for separation of families of services1 (e.g. VCs for each of voice, video, management, and data). Use of a single VC (or VLAN) to support multiple families of services will require demonstration that this is necessary to meet the specific customer/application requirements. Departures will need to address the known issues with using a single VC (or VLAN), e.g. traffic separation at the IP edge.

3. ATM / DSL connected services will use multiple VCs to the CLNE where multiple QoS profiles are required. Use of a single VC to support multiple QoS profiles will require demonstration that this is necessary to meet the specific customer/application requirements. Departures will need to address the known issues with using a single VC, e.g. higher bandwidth provisioning, measurement & reporting etc.

4. Additional VCs between the network and CLNE may be provisioned if specific applications require a separate VC. However, it will be necessary to demonstrate why the "basic" VCs cannot be used.

5. As Ethernet Access may support multiple QoS profiles, the CLNE used for Ethernet Access must be capable of either doing traffic classification by QoS profile (using 802.1p) or remarking traffic already classified within the customer’s network.

6. There will not be any special provision within the Telecom network to address the variability of QoS performance inherent in the BCL network.

7. SDX will only be used as a policy front end for the ERX; redirection of customer HTTP traffic to captive portals based on certain business rules; and per-user accounting via RADIUS records.

8. SRB will perform dynamic (mid-session) policy changes that arise from business rules related to usage (e.g. certain limits imposed) or customer self-provisioning. The SRB communicates with the ERX via the SDX (using SOAP) to effect the policy changes.

9. The target for QoS management is to use the SRB for admission control and VC resizing without overbooking in the ATM network. However, this capability will not be available until SRB 2.1 (end 2004). In the interim the SRB will employ CAC using pinholing and an overbooked ATM network.

10. Probes will be used to normalise and calibrate SLA performance inferences drawn from statistics obtained from network elements.

Notes/Guidelines 1. Guideline: It is preferred that multiple QoS profiles be supported within a single VLAN, however it is noted

that there are circumstances where multiple VLANs are required.

1 In this context a separate VC or VLAN is required wherever families of services require separation at layer 2. The acceptable reasons for L2 separation are: 1. Services require L2 termination on different IP edge devices (e.g. BRAS vs. PE). 2. Services require L2 termination to different VPNs (e.g. the PSTN voice VPN will be separate from a community

of interest VPN). It is expected that there will be three main service families requiring L2 separation i.e.: 1. Voice: PSTN voice and associated forms of video conferencing, 2. Video: high quality video and audio (e.g. broadcast and PPV to the TV), 3. Data: general data services (including PON family, communities of interest, internet access etc), 4. Management will also be separated at L2 in accordance with the Security Rules. Some data services such as PON family may be packaged with other services such as PSTN voice. Whether these are built as a single service or not in this context will be part of the solution design (e.g. the solution could be a single data service with a back end connection to the Voice VPN or alternatively two services directly connecting the CLNE to the Voice VPN and the PON VPN using separate VCs or VLANs.



2. Guideline: Definitions of QoS terminology contained in the glossary of this document should be employed in a consistent manner across all NGN projects to aid common understanding.

3. Guideline: A common set of QoS profiles will be used for as many applications as possible to maximise re-use and minimise the number of configurations required.

4. Note: The requirement for effective traffic management to ensure that QoS standards are met assumes the existence of effective processes and systems for Operational Support and Readiness. The fact that there is no current focus in this area constitutes a gap that needs to be closed.

Options for support of mixed data services

Note on QoS related semantics: Quality of Experience (service quality) - does it do the job it needs to do (marketing view) A Configuration Profile is the intersection of QoS class, bandwidth and class of equipment A Configuration is the device specific implementation of a configuration profile Class of Service Class of Service refers to the logical grouping of network, system and process performance attributes into classes to which services can be assigned. This term is not used to refer to QoS in the network it is more closely related to the Quality of Experience.



Appendix D. EAI and Meta Directory

Background

Telecom has over 250 primary systems. Historically these systems have each implemented their own identity, authentication and authorization mechanisms and connections between systems have been implemented on a point-to-point basis. The resulting complexity is unsustainable in terms of both cost and responsiveness (e.g. ICMS alone has over 700 separate connections to other applications and changes can take several months).

Three strategic initiatives in the Enterprise Application Framework (EAF) address this problem: EDB (Enterprise Database) is a logical database which is the master repository of enterprise information including customer details. It will comprise several backend systems each dedicated to a particular type of data. The first such system to have been implemented is an Oracle customer database utilizing the Oracle TCA (trading community architecture) schema. Use of the term EDB is to be avoided (refer instead to the relevant specific systems) but this definition is presented for the sake of clarity. EAI (Enterprise Application Integration) uses the Crossworlds toolset to externalize reusable functions and thus enable a hub-and-spoke application architecture with EAI at the hub. The EAI also provides workflow and synchronization tools so that information is persisted in the necessary target systems. Meta Directory uses the Novell e-Directory product suite to provide a set of directory-style interfaces (LDAP, RADIUS, SOAP etc) into the customer profile information mastered in the EDB. It primarily uses the TCA schema but provides integration between other operational slave directories and the EDB through business logic rules for schema translation.

The Meta Directory is therefore the primary interface between network/systems AAA and the EDB. The AAA environment is also tightly related to resource allocation, policy, state and Presence as described in the Architecture Walkthrough sections 2.8 to 2.12. The following design rules and guidelines are presented as a useful summary for NGN deployment. However, the reader is referred to the existing detailed EAF publications on EAI and Meta Directory as the primary points of reference.

Design Notes 1. Any data that needs to be accessible outside a particular domain needs to be accessed through the EAI. 2. Any data required for business continuity should be mastered in the EDB. 3. Profile information required for real-time service delivery must be accessed through the Meta Directory. 4. Profile information is provisioned via the EAI (which ensures propagation to EDB and Meta Directory). 5. Products that expose a customer self-configuration capability must do so through the EAI (i.e. direct web

interfaces into products such as SDX, ePhone-C, Openwave etc should not be used). 6. The Alcatel SMC will be used as the primary RADIUS Server (i.e. end of the RADIUS chain) for Telecom

services (including XTRA, mobile and NGN). 7. All RADIUS requests must be proxied via the SMC (so that state information can be externalized). 8. All applications must access authorization and personalization information from the Meta Directory.

Notes/Guidelines 1. The Meta Directory project is currently underway. Several capabilities are available today but on occasion

capabilities required by a particular project may not be available in the timeframe required. Projects should therefore establish early dialogue with the Meta Directory project (via Brian More [email protected]) to understand any practical timing issues around the above rules.

2. Where there is a very small number of technical users (i.e. 1-3) associated with a particular product (e.g. 5020, Ephone-c, SMC, CMC, OSP, 5620) there is not a requirement for authentication and authorization of those users to be integrated with the Meta Directory. Refer security rules for more info.

3. The EAI should be used where there is a likely-hood of a function being reused by other systems. However, there is no need to interfere with the interworking of tightly integrated sub-systems.

4. Latency may be a significant consideration in certain real-time provisioning situations (e.g. prepaid mobile). In such situations the latency implications of provisioning via EAI/Meta should be measured.

5. The EAI may facilitate disaster recovery in the future by synchronization through dual EAI hubs. 6. The SMC can and should be deployed in a highly available configuration.



Appendix E. Mediation, Financial Authorization, Rating and Billing

Background

The Telecom Billing Program is focused on three primary systems – Commerce Engine for real-time financial authorization, Intermediate for high-throughput post-event mediation (i.e. assimilation and normalization of accounting records) and Convergent Biller for generating billing information (with ICMS initially continuing its roll in bill presentment). A generalized view of this solution and connection to the EAI is shown below:

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!��

�� "�� "��

#��$� ��%%�� $� #��$� ��%%�� $�

��

��"��

��

��"��

��&��"��

��'� �(��

��&��"��

��'� �(��

��)��)��

* ��+�#��

�""��"� )��)��+��

Intermediate

Commerce Engine

Convergent Biller

*

�� "�,��-��

�� "�,��-��

Design Rules 1. All usage records go to Convergent Biller via Intermediate or Commerce Engine.

2. Commerce engine is only used for real time financial authorisations (i.e. response required <100msecs). Other accounting records go to Intermediate and then to Convergent Biller.

3. Where usage information needs to be directly obtained from network elements or Element/Domain managers (i.e. other suitable usage records such as RADIUS accounting records or CDRs are not available) this information will be fed to Intermediate via the Performance Management system.

4. The parties involved in service creation must agree a metering model as part of a new product design.

5. QoS SLA rebate events must be available through the EAI to be handled via Convergent Biller (i.e. rebates are a rating function – they are not handled as negative events through mediation).

6. All orders or purchases (except micro payments) must occur via the standard order entry process.

7. All new services are to use Convergent Biller with Intermediate and/or Commerce Engine. If the billing project is unable to accommodate the new service in its work programme then a stand-alone instance of this product suite should be used and merged into the production platform at a later date. (This option is undesirable but better than the alternative of proceeding with an interim solution based on other products).

8. Billing to and from 3rd parties should occur via Convergent Biller (this includes wholesale billing).



Notes and Guidelines (Mediation, Financial Authorization, Rating and Billing) 1. Categories of service that will be offered include real-time services (e.g. voice, video conferencing),

messaging (e.g. voice-mail, email, SMS) and content (e.g. Video, HTML content, WAP content). Content services that are primarily delivered through web server technology will use a common session/State Server (refer AAA, Meta, EDB, EAI paper). For such services it is desirable that the session/State Server would be the primary source of accounting/usage records since it already records session information. Where this approach is taken, applications should provide both session initiation AND session completion records with suitable accounting information to the State/Session Server (preferably via SOAP).

2. As with other process domains, any sequence of tasks should be handled by the enterprise workflow system (i.e. business process transaction management system) when it has been deployed.

3. Precise network time-of-day synchronisation is needed for billing event correlation in the mediation engine. 4. Application session termination information should include Mbytes information for successful and

unsuccessful downloads so that the Mbytes can be subtracted from overall Mbytes usage. 5. Cut-off for billing/credit reasons needs to be graceful:

a. Warnings b. Consider a sequenced cut off of services (e.g. least critical first) c. Redirection to a web-page, IVR or CSR as appropriate so the customer knows what is going on.

6. All accounting records go to Intermediate (except for real-time authorized services) and it decides what to do with them. This includes non-billing applications such as redistribution to capacity planning.

7. Failure of Commerce Engine should not stop service – within acceptable risk limits service should be able to continue. (In practise, during Commerce Engine failure CDRs will go to Intermediate which will produce a "parachute CDR" for Convergent Biller).

8. It is expected that the EDW project will handle reconciliation of aggregates (subject to confirmation). 9. Policy execution points (PEPs) execute policy within the network. At present the technical solutions available

mean that the PEP (e.g. ERX) or a proxy (e.g. the SDX) needs to poll a directory for mid-session policy changes (e.g. based on billing events). A more desirable approach would be that policy is established at the start of the session and that such policy includes the alternative policy states and a mechanism for setting the amount of time before the PEP checks for policy state changes (e.g. by means of a “token”). To illustrate, a single “policy::=session will exist for 5 minutes then re-authorise or terminate” is preferred to a sequence of policies: “policy1::= session is allowed” then 5 minutes later “policy2::=session is disallowed”.

10. Friendly garden and off-Net content can be authorised, mediated, rated and billed in the same way but off-Net will require a Federated Identity.

11. PSTN location based billing: Directory number will not be a direct indicator of location. It is desirable for performance/complexity reasons if source/destination location information is in the CDR. It is currently expected that the number location information will be mastered in the Logical Inventory, i.e. Axioss IMS (subject to confirmation)

12. To support IP destination billing, IP edge devices need to support data-gathering based on destination class summarisation or NetFlow-like summarization. Such data would not be available via RADIUS records and so would be collected via the performance management system and fed to Intermediate.

13. The term ‘Funding Hierarchy’ refers to a delegated account structure (e.g. a parent provides a monthly allowance for a teenager to spend). When funding hierarchies are implemented (a future plan), INFO will need to feed the funding hierarchy structure to Convergent Biller (as part of the Order Management workflow). Convergent Biller will then persist the Funding Hierarchy as distinct from the identity/authorization hierarchy persisted in the Meta Directory.

14. User identity should go into CDR where possible to simplify the mediation, rating and billing processes. 15. Systems accumulating records for VPN usage and performance must be able to associate records with

appropriate VPN identifier e.g. by correlating accounting records to LI VPN identifier. This strengthens the case for a single integrated Logical Inventory that includes VPN Management.

16. Key parameters of the customer contract need to be available to the Business Correlation system so that SLA events can be determined. Such SLA events would be passed off to the enterprise workflow system which would trigger an SLA rebate in Convergent Biller (as well as any other SLA event handling processes).



Appendix F. Fulfil

Design Rules

General 1. Quotes are a special state of an order (an unbooked order) and both are persisted in Order Management. 2. Self provisioning is to occur through the EAI and associated front end systems, not directly via web front ends

on Application Servers. This is to ensure a full record of changes and the ability for the front office to assist with trouble shooting.

3. Order Feasibility does not persist any data - only rules. 4. Customer configurations may be stored locally for operational reasons (e.g. desktop configurations in

ePhoneC) but they must be mastered in EDB. 5. Fulfil and assure must use the same common test management function accessed via EAI. 6. The process of fulfilling an order is distributed hierarchically between a top level workflow management

system (one of the common functions) and business function specific workflow managers for example AXiOSS O2S for Service Provisioning.

Inventory Systems 1. Logical Inventory must include a logical view of all network resources including the physical so that products

can be defined solely in terms of Logical Inventory. 2. Target systems for Inventory are as follows:

a. Physical plant: NetMAP. b. Physical RME (Rack Mounted Equipment): unresolved. c. CLNE (stock): unresolved. d. Logical: AXiOSS IMS. e. VPN and configurations: AXiOSS IMS - subject to confirmation of suitability. f. financial asset management of CLNE - SAP subject to confirmation.

Numbering Systems 1. Target systems for PSTN number management roles are:

a. Registry is Alan Fagan b. PSTN number is Logical Inventory therefore provisioned from numbering module in AXiOSS

Logical Inventory after it has been confirmed as suitable. c. Number should be made available from MetaDirectory as an aspect of identity.

2. Target systems for IP address management roles are: a. Real time dynamic allocation - SMC b. Static allocations (e.g. n/w elements, customer nodes, ranges for dynamic allocation, etc) - AXiOSS c. Registry - under consideration (Alan Fagan).

Notes/Guidelines 1. CLNE and CPE need to appear in Logical Inventory and Physical Inventory. 2. Order Feasibility confirms the technical capability of the network to deliver service (e.g. that the customer is

in the coverage area) not that resource is available right now. It therefore relies on effective Operational Support and Readiness processes to ensure resources are available as required.

3. Operations Support and Readiness requires further explanation which is provided in the glossary.



Notes on Related Heritage Systems

FAIMS data migration

Data Target

IP services Logical Inventory Logical Inventory AXiOSS

Fault management …do as part of assure

Provisioning (workflow for data services except sub rate)

AXiOSS Service provisiong

AAA Rate limiting proxy config AXiOSS Logical Inventory

Customer data Installed Base - doesn't exist but is part of EDB

DSTN Alarms Accessed via Business Correlation



Business and Common Functions

This diagram shows a subset of the business and common functions that are associated with the fulfil processes. The highlighted blocks are those IS functions most impacted by the fulfil architecture. The callout notes identify the status of the individual functions.

Product book

workflowmanager

order feasibility

Installed base

Credit Check

EAI

contact history

customer

contract / SLA

Stock, AssetRegister,

(SAP)

ICMS

EDW / Probe

work force mgmt

Problem Mgmt

OrderManagement

Serviceprovisioning

Logical Inventoryincluding: VPN

Numbering

PKI

ConvergentBiller

EDB Correlation

PhysicalInventory

Test Mgmt

Meta Directory

Integrated Front Office

Order Entry CustomerMgmt

Know base

NAS

PSTN

Under action as partof InFO project

Sales Tech & EDSdevelopjng salesaspects of productdata model

Proposed as part ofTransformation Phase 4

no action on genericcapability

Proposed as part oftransformation phase 4

Existing system (DecisionPoint) is adequate fornow

Exists. 360 Project hasdelivered first phase(read only copy ofICMS data) on OracleTCA schema.

Proposed as part ofTransformation Phase4

no current actionplanned

Proposed as part ofTransformation Phase4



Proposed as part ofTransformation Phase 4

AXiOSS components

InFO will initiate useof AXiOSS IMS

(NetMAP / Small World)Cable planning and customercable records exist or are u/a.

No current action planned RMEor CLNE

Exists in development:adequacy of schema is

still uncertain.

exists in developmentin Bill project


NGN etc



Semantics Note

What is Operations Support and Readiness?

Operations Support and Readiness is one of the processes defined by the TeleManagement Forum in the eTOM framework. It fits into the operational group of processes along with Fulfil, Assure and Bill. It differs from these by being less directly customer focussed. eTOM describes it as follows:

This process is responsible for support to the “FAB” processes, and for ensuring operational readiness in the fulfilment, assurance and billing areas. In general, the processes are concerned with activities that are less “real-time” than those in FAB, and which are typically concerned less with individual customers and services and more with groups of these. They reflect a need in some enterprises to divide their processes between the immediate customer-facing and real-time operations of FAB and other Operations processes which act as a “second-line” in carrying out the operational tasks. Not all enterprises will choose to employ this split, or to position the division in exactly the same place, so it is recognized that in applying the eTOM Business Framework in particular scenarios, the processes in Operations Support & Readiness and in FAB may be merged for day-to-day operation. Nevertheless, it is felt important to acknowledge this separation to reflect a real-world division that is present or emerging in many enterprises. The separation, definition and execution of the Operations Support & Readiness processes can be critical in taking advantage of ebusiness opportunities, and is particularly important for successful implementation of Customer Self Management.2

2 GB921, enhanced Telecom Operations Map (eTOM): The Business Process Framework, TeleManagement Forum, Version 3 June 2003. Page 24.



Appendix G. Assure

Design Rules 1. The assure architecture must include common event correlation and performance management across

the process, systems, application and network domains. 2. The performance management system will be the sole master repository of performance information. 3. Event Correlation will be the sole master repository of high-level network, systems and application

events. 4. The problem management system will be the sole master repository of pre-plans (see glossary). 5. Both the performance management system and event correlation system will be accessible via the EAI. 6. Any test required in support of fulfil or assure processes or self-test or service management companies

should be executed via a Test Management system that is accessed through the EAI (refer glossary for definition of Test Mgmt).

7. Events must be time stamped. The time-stamping functions must use a reliable and accurate source of time-of-day information (e.g. GPS or a network time server).

8. An SLA/Contract Management system is required. This system should store data in a manner consistent with the Business Correlation system.

9. Self Assure functions are accessed through the EAI. 10. Service definitions must clearly articulate the service assurance demarcation point (which may differ

from the network demarcation – e.g. set-top box service demarcation with IAD network demarcation). 11. Assure systems must be decoupled such that an assure system failure does not impact service delivery. 12. All elements in a service delivery chain should generate events on error. Such error events should

include sufficient information for correlation to individual sessions so that faults can be isolated. 13. Performance management should generate alarms for both positive and negative thresholds (for

management of service differentiation)

��

� �!�� !��

�� !��

��

�$�� $��

��

��$� ��

��

��$� ��

��

��

��

��

��

��

�� "��

+��

��

+��

��

��

Notes/Guidelines 1. Projects must build mechanisms to identify QoS problems on the customer side of the CLNE (i.e.

isolate the problem to the customer side or the Telecom side of the demarcation point). 2. Note: A network model capability is required against which the impact of maintenance, promotions etc

can be assessed. 3. Note: May need integration between NGN & PSTN management though this is probably primarily a

front office problem. 4. Note: Don't need to know reasons for faults/SLA mgmt - you do need to be able to classify SLA

performance, so you need to be able to measure what the SLA specifies (not necessarily cause) 5. Note: The enterprise workflow system (i.e transaction management) manages the sequence of events

required to restore, repair and normalise following determination of a Business Correlation event. 6. Note: Need a reporting system that is EAF compliant (i.e. accessed through CCI/EAI) 7. Business Correlation needs to distinguish between designed performance levels and problem

performance. For example, the network may be designed to fail 1% of calls because of resource limitations (so failed calls are not necessarily indicative of a problem).

8. There is a requirement to assure voice quality. Initially this would be achieved by collecting per-call performance information. Once confidence in the technology is gained a sampling approach may be sufficient to manage ongoing performance.

9. Assure scope includes responsibility for defining the sequences of common functions required to restore, repair & normalise.

10. Performance data should include billing event thresholds from Intermediate for the purposes of detecting billing problems, revenue leakage etc.



Semantics Note.

The following illustrates how particular terms should be used in the ‘Assure’ context:

Event - something that happens out in the network or a server farm an event causes an Alarm to be generated in a Network Element (NE) an Element Manager (EM) is the system which gets the alarm from the NE. Domain Manager (DM) gets notification of the alarm from the EM. The Event Correlation system collects events from a variety of Domain Managers and other sources and groups and filters them into more meaningful events (i.e. events that may require action). Alarm converters are subsystems of the Event Correlation system that change the format of the alarm from the native Domain Manager format to the internal format used by the Event Correlation system. A Probe is a network element used to measure performance. A Fault is something that needs fixing -- either reported by a customer (inbound) or arising from alarms. Alarms can be a warning, not necessarily notification of an actual fault condition Problem management is the system that deals with faults and other customer problems (is the same as trouble management), including evaluation to determine whether something needs to happen common function is the management of problems whether customer reported or arising from alarms etc The Performance Management system is where performance data is aggregated and from which trends over time can be determined. Threshold events come from performance management Events can come from many sources e.g. mediation for CDR tags The Business Correlation system correlates between high-level events from the Event correlation system and data persisted in the core business systems (such as customer, SLA, product and Logical Inventory). The Performance Management system needs to understand what its thresholds are, and some of those will be determined by SLAs. Performance management not only counts events and alarms, but also other parameters and contains historical information relating to all parameters captured. Analysis is a separate function which relates Logical Inventory to performance SLA management triggers business processes related to SLAs. Performance reports may be generated by performance management. SLA reports are a superset of performance reports and include the relationship to customer SLA.



Appendix H. Outstanding Issues and Actions

Outstanding Issues and Actions - Assigned

IP Address Management

1. Which system(s) handle real-time allocation of IP addresses for PPP and DHCP and how do the address pools get provisioned? The expectation is SMC for real-time PPP, while DHCP is not determined. Data Core project to resolve based on outputs from CCIA project.

2. Establishment of address utilization reporting mechanisms. Alan Fagan to investigate.

EDB, EAI, Meta Directory and AAA

1. Determine mechanism for synchronization between SMC and Meta Directory. Data Core to resolve.

Security

1. Carl Grayson will compile a threat tree.

QOS

1. Data Core to define QOS classes for Voice Plus and configuration profiles for all services implemented during the duration of that project.

2. Service projects are responsible for defining the QoE (Quality of Experience) requirements from which Data Core will define necessary QoS and configuration profiles.

3. Data Core will determine end-to-end QoS budget allocation. 4. Data Core to investigate options identified for virtual circuit configuration for a combination of

connectivity-based data services (e.g. PON) and session-controlled data services and resolve which is the preferred scenario.

5. Data Core to resolve how the ABG/SRB IP address interaction will work with NAT, with interaction with Voice+ as required. The Data Core solution will then primarily drive Support System requirements.

6. Voice+ to investigate how 111 call obligations will be met, with assistance from Data Core project as required.

7. The Data Core test schedule will examine NE performance under load (Note: it is not clear yet whether the tools exist to do the necessary testing).

8. Data Core to assess NE behaviour under high resource utilisation during testing phase to assist with prediction of network performance under possible or future scenarios.

9. Data Core to determine appropriate probes to perform calibration of SLA performance data and sample QoS performance on an ongoing basis.

Assure What is in a CDR? Voice+ to consider whether call performance data should be collected in CDRs Where does call quality information come from, or reasons why a call is terminated? Voice+ 1. Assure scope must include end-to-end process assurance – Assure Project when commenced 2. NetCool rationale to be articulated by Alcatel

Financial authorization, mediation, rating and billing 1. Identify enterprise workflow system (for business process transaction management). Action: IS (future) 2. Identify Micro payments systems (including aggregation if required). Action: Billing/IS (future)



Outstanding Issues and Actions - Unassigned

IP Address Management

1. What is the IP Address Management Policy for multicast traffic? AGG to assign accountability.

2. Impacts/Timing of IPv6 requires further consideration. AGG to assign accountability.

EDB, EAI, Meta Directory and AAA

3. Investigate mobile issues (e.g. implication of DIAMETER/RADIUS extended attributes, provisioning latency considerations). AGG to assign accountability.

4. Architecture for integrated view of session/state and Presence including appropriate single-Sign-on mechanisms. Assess whether integrated State Server is based on further development of Session Master, a third party product integrated with State Server or a new solution. AGG to assign accountability.

5. Determine how to delegate authority for voice services (e.g. teenager call budget). AGG to assign accountability.

Security 1. There is a need for further distinction between the following issues. AGG to assign accountability.

a. L2 and below and Layer 3 and above in the security zones model. b. Customer traffic that transits network nodes and terminates on servers and internal node to node

traffic. 2. Review application of security to BCL POI. AGG to assign accountability. 3. Ensure appropriate capabilities for lawful interception, call trace and preferential routing of emergency calls

with associated security are developed in voice projects. AGG to assign accountability. 4. Review security for Peer to Peer traffic between customers. AGG to assign accountability. 5. Determine physical location of firewall functions. AGG to assign accountability.

QOS

1. Define an activity to identify Application Profiles for a base set of services. AGG to assign accountability

2. Determine responsibility for validation of application and QOS classes. Ensure long term ownership and understanding, including establishment of a repository if necessary. AGG to assign accountability.

3. Explore methodology, tools & capabilities required to support planning functions. AGG to assign accountability.

4. Ensure alignment between measurement data being generated for SLA monitoring and Assure processes utilising that data. AGG to assign accountability.

Fulfil

1. All issues require the AGG to assign accountability. 2. Need to know timing for when systems that replace existing non-compliant heritage system be available,

how long can we continue using and enhancing them. 3. Generic Order Feasibility function. 4. CLNE and associated Stock management function. 5. Common Test Management and Problem Management function to support fulfil and assure processes. 6. Work Force Management function. 7. Operational Support and Readiness - i.e. the processes and systems that ensure that there is adequate

network resource to fulfil customer service requests in a timely manner. 8. Rapid processes for working with EDS will be required to speed up the introduction of new self service

capabilities.



Assure

1. Scope the Operational Support and Readiness domain (addressing both Fulfil and Assure dimensions) and identify activities needed to address. AGG to assign accountability.

2. Resolve Business Correlation and SLA/Contracts schema interworking. AGG to assign accountability

3. New project workstreams are required to address the following areas (AGG to assign accountability) • Test System (to make test capabilities available to front-end and other systems) • Performance Reporting including SLA Reporting (ability for customers to extract reports

based on data in performance mgmt system correlated with other information) • Business Correlation (correlate network/system events with customers, SLAs, services etc) • SLA/Contracts System (an IS project is planned in this area). • A dedicated Assure programme needs to be defined and implemented (underway)

Financial authorization, mediation, rating and billing

1. Specify how PSTN replacement billing will work (prepay etc) What is required in billing to make fixed voice mobility as flexible as cellular mobile. Action: AGG to assign accountability.

2. Credit card authorisations etc for content - how will this work? Action: AGG to assign accountability.

3. Location based billing in the NGN: what is the requirement, how do we collect the required source information. Especially for IP data. Plus how often will it be required. Action: AGG to assign accountability.

4. Location based billing for POTS requires location information to be in the CDR or inferred from info in CDR (e.g. the numbers). Which approach is best and which databases would hold the relevant mappings. Action: AGG to assign accountability..

Other

1. Reports. A self-reporting module to enable customer self-service of SLA and Performance Reports. This is a separate function from Performance Aggregation and the solution need not be part of the general Performance Aggregation solution.

2. Consolidation of AAA chain. Investigation of practical limitations versus architectural desired state.

3. Messaging. This area was specifically outside the CCIA scope but needs to be addressed at an enterprise architecture level.

4. Resolve inventory issues for 1) RME, 2) CLNE Stock (as above), 3) VPN Mgmt, 4) CLNE Asset Mgmt

5. System and Application Management. How is the ‘Element/Domain’ and alarm chain to be implemented for systems (presumed largely in place) and applications (presumed not in place for bespoke apps).



Appendix I. Description of Big Picture Functional Components

This section describes the main functional components shown in the Big Picture along with the associated data that is mastered or synchronised locally. For definitions of other terms please refer to the Glossary of Terms and Abbreviations:

��

��

��

��

��

��

��

��

��

�� !��"� ��

�� #�� !��"��#

�$�� !��"� ��

!�� $��%!� �� &'� �� #

�� &��

��

��$� �� (�� )� ��

)� � �� !#��

��$� �� #*��

�� +�� +�� +� �� ,��

�� "��

�%$�� %�� $��%$�� %$��



��

��

��

(��"�� $� ��

�� "�� " � ��

!�� (��"��

&��

(�� (�� )� ��

��

��

%��"��

(�� (�� )� ��

�� !��"�� $�� -��+ ��+�� #��

�� +�� -��+ �� +�� +��

�� #��

�� . � �� . �� %!�

!�� . ��

��

�� "��

�� %��#

%�� "� �� + �� &��'� (�� /+ � ��

!-�� !-��

�� 0�� (�� )� ��

0�� 1�� 1��

��

*�� -��

!��



��

��

��

��

�� ,��

*��

�� ,��

�� 2��

0��

��

*�� - ��

!��

��" � �� (�� )� ��

�� .��

��"�� &�� +�� .�� (��

�� (�� )� ��

�� + �� + ��

�� +� ��+�� + �� + � � �� "� �� + � � ��

!��

&��3�� (�� )� ��

&��

�� #&3��# ��&��3��

0��

!��

&�� &�� !��



��

��

��

&��$ &��$��.�� !��"�� &�� %$ ��

#�� 2&�� $� �� !��"� ��

�� "��

#.�� 4567 � � �$� � ��' ��

�� " �� "��

#��

8�� !��" � �� "+ �� #��

# ��*�� #*��

�� )� ��

�� + ��9��+ � � ��

)� � �� + ��+��9�� +��

(��

#�� #��

!��"�� 0��#��

#�� !��"� ��

�� &�� $� �� ,��

�� *�� "��

#.�� *�&�'� �*�&�'� �� .��

�� + ��:��

��*�&�'��

)%� )%�� )��

8%/ � 8�� %�� *��

� ��



��

��

��

� ��(�� (�� )� ��

0�� ,�� ;��$� ��

��(�� $��)��#

� ��

��

!��

��#�� %��(*�� #�� !��"�� *�� 6�<

0�* 0�� *��

�� "�,��

�� (�� )� ��

� �� "��=

� �� "�

� &��'� (�� "� �� (��

� � ��

� �� " � � ��

� ��

!��

$�� $�� $��

$�� !��"� ��

��+ ��

*�� + �� " � � �� *��#



��

��

��

$��&�� $��&��

� ��

%��+�� + �� +�� +� ��

'�� "��-�� +

��

$�� +

�� +�&��+��

$83 $�� 8�� 8� �� %!��

!��"�� "� �� "�

$� ��'�� !��"� ��

�� +��"� ��! ��

!�� .��

$��

$�� $��

$�� $� �� !��

!#�/ %��.�� %!�.�� !#� ��%! ��"��



��

��

��

!��"�� !��!��#

%�� "��.�� "�� !��!��

)��.��.�� >��$� ��? � � �� ,�� !� �� .�� .+ �� .�� %��.�� .�� "�� "��

!�� !��

!��"�� !��!��#�

%�� "�� " � �� !��!��%!��

!-�� !-��

!� ��%�� !��"� ��

*�� +��

�� !� �� ,��(�!��+#

*��

;��)�� (�� )� ��

(��

��

&��



��

��

��

;��$� �� (�� )� ��

�� .��

%�� "�� "�� "��+��,�� + ��,�� + �� (�� -��

��' ��

;�� @�� "��;��

&�� (�� "�� ,��

$� �� ,�� ,��

�� 9��

��"�� (��

!-�� !-��

�&�! ��"��&�� !�� !��"�� &$� ��"� �� !��"�

�� !��"� ��

�� "� � � ��

��

*��

��

�� "+�� +��+� ��

��

8� �� #��

8� ��

��#��,��

!��=

� ��

� �� .�� $��#��



��

��

��

�� (�� )� ��

0�� " �,��

� �� + ��" �� ,�� + � � �� 8��

!��

�� !��" # ��

*��+�� "��

��-��,��

�� +�

��

!�� 1 ��1 �� "��

��(��" � �� (�� )� ��

0��

��-��' �� (�� + �� *�� "��

!�� !��

�� $� �� (�� )� ��

��

*��

��

�� +�� +��

*��

�� "��#

� �� "�� %�� %�� (�� '��(��

!-�� !-��



��

��

��

��(��" ��

�� (�� )� ��

��"�� %�� +��

��

� &�� A��

� ��

� *�,��

� ��

�� .�� ;�� # ��

�� (�� )� ��

(��

!�� #.�� $��)��#

� �� %��)��+#

�� @��+ ;��+"��.��++"��/��,$�

�� "��#

%��%��

!-�� !-��

��%!!�� !��"� ��

%�� !��" �� %!�.�� ! � � �� "��

%�� %�� ,�� +

�� ,��+

$� �� 9��

�� &!� ��

�� ' �� *�� '*�� !��= � �� &!� �� "��

� ��'*�� &!��

��

�� '*��



��

��

��

��%!8�� %!�� $83� *��$83 *��$83

*��.� � �� !��" # ��

�� -*$�(0��!��

��*$�(0��!��

� �� *��

*�&�'��

��$��$��

*�� (�� )� ��

�� #

�� +� ��+� �� +�� "� �� -� ��

*��%��)� � ��

�� !��"� ��

�� BA77�� "��

�� 8� �� "� � �� ,��

'��

*��$� �� +��

*�� $� �� + ��

*��

(�� #�� + ��"��

*�� ,��

*� ,��#��

��



��

��

��

*��(��"��

$�"�� " �� "��

*�� "��,��(�!��+��

��

C��,��

��

*�� "��(8+&��$+��!#+��

*�� (�� .� �� "��!8!��$��#�� (�� "��

!��"�� "�� "� ��!8!�

�� + ��

!��

��

�� "� ��

!�� C�� $� �� + ��+ � ��

�� !��"� ��

3��"�� ,�� " ��

&�� "��- ��" �� &��'�"��)��#

�� "��

�� "��

#.�� "�� ,��

�� 9��

��

�� + "�� "�� $�� &��+ � �� "� �� +��"��

��

�� ,��

��



��

��

��

�� ; � ��

!�� +#�

'��!�� "� ��

��$� �� 2 ��

!�� 2��

�� $� ��

��

��

�� C�� "�� +0�D6D# �� +%�� "8��

��

*�� + �� + �� ,��(�!��+#

*��

��

�� %!��

%��$� �� !��"� ��

�� ,�� "�� +��+�� ,��

%��,�� #.��,��

� �� "�� .��

'&&� � ��

0��+ ��+ � �� %�� /$��

*�� (�� + /$� �� +� ��$��E��

�� ,��



��

��

��

%� �� %! �� %!��

��%!�� %! ��"� �� ? ��"��

%#/ F%;�%#+ #.�� /��G� %�� 9�� %��?� ��

C�� '�� (��

' ��

&�� $� ��

C��)�� (��8��(8��

!��"�� ;�� F�� G� ��!8!��

C�� C��

$� ��

C�!$� �� (�� )� ��

$� ��C�!��

�� ,��(�!��+#�

� �� (��

�� C�!��

*�� C�!��

�� C�!��

*�� C�!��

3��83 � �� " � ��

%�� 3�� H� �� )��!�� 3��

*��

��

%�� 3��



��

��

��

3� �� " � ��

%�� H� �� %�� ,�� ,��

*��

��

3��")��$� �� (�� )� ��

�� +�� "�� " � �� 3)$ �� "��,�� "� ��

3��"��

�� "��,��

��"��,��

*��9��

3��"�� (�� )� ��

$� �� ,�� + ��

��,�� #.�� "�� ,��

�� 9��

/$�8��

�� /$��(6(�� + � �� .�� '&&��#��

!�� *�� /$��,��

��

�� #��



Appendix J. Glossary of Terms and Abbreviations

This glossary is in alphabetical order by "Abbreviation" (if there is one) or "Term and Abbreviation Expansion".

$))��!�� 1��$))��!��2��

��

4767 � �� %�� %��C��

4567 � ��&�� $� �� -�%$-&�� "��

�� +�� +� ��

%�� " �� +�� +� ��

�(8 ��(��8�� %��(��8��" �� .�� )�� "��+!�%-��%+� ��8� �� *(�

��

��

��&�� )� ��

��8 �� 8�� 8�� !#�� C�� %$��)�

�� #�� &�� $� �� !��"��#�

��&�� )� ��

�$�� $��

��&�� )� ��

� ��&��

�� +��

��#�) %�� # ��)��"�#�)��%��#�)�� #.��#�) � � � ��

�� &�� )� ��

��$ �� $��.��

��&��$��



$))��!�� 1��$))��!��2��

��

��(; �� (�� ; 9��

�� (�� ; 9�� F��G�%�� 9��,�� #��8� ��(�� ; 9�� %�� 9�� ,��F�� G��,�� 8� ��(�� ; 9��%�� 9�� 8� ��(�� ; 9�� ,�� 8� �� (�� ; 9�� C�� 3-%��

��) �� )�� (�� 8�� (8� �� " �� .��

��! �� !� �� ,�� "�

�� %�� .�� @�� %�� +� �� + � � � �� + ��

��$� �� )� � �� !#��

��&�� )� ��

�/�;��;6� ;�� /�;�� =�.�� +��"� ��

�/�;��)# �� )��"# ��

�� "� ��,�� /�;�� "� ��

(�� %�� + �� +�� + � �� + �� ,�� +�� ,�� H� �� %��

(��

��&�� )� ��

(��"��;�� %�� ,�� #�� %��

%��(��"��;�� @��



$))��!�� 1��$))��!��2��

��

(�� -��+��+�� #��

��&�� )� ��

�� #�)�� "��-��

�&* ��&��*�� %�� &*�� +��%!��+��%!��+��

�&'� ��&��'�� &��'��+ � �� I�� .�� !#�� %��

�� %�� %�� +� ��

%�� %�� 3��+��

��!# ��!��"#,��

%�� " �,��

�$� ��$� �� &�� $� ��

�!� �� !��"� �� #�)�� "� �� "��-��

��(�� )� �� %�� %��

�� %�� "+ �� %�� .��

�� %�� "�� + �� " �� /+� ��

��&�� )� ��

Conklin Mini DSLAM, a DSLAM with a physically small size and low termination capacity.

�� 0�� 0�� 1�� 1��

��&�� )� ��

�� %��

�� ,��

��&�� )� ��



$))��!�� 1��$))��!��2��

��

�� %�� @��+ � �� ,��

�� 2�� 0��

��&�� )� ��

��(�� )� �� %�� #�) �() �� (�� )� �� (�� +��(��"��

��" �� .��

��&�� )� ��

��* ��*��

��

��A��6�

�� + �� +��

��&�� )� ��

��6��6�

��%��

&��3��#&3� &��

��&�� )� ��

&#! &��# � ��!��"� &�� # � �� !��"� �&#!� � � �� " � �� %��

&0�� Dynamic Host Configuration Protocol

A protocol for automating the configuration of computers that use TCP/IP. DHCP can be used to automatically assign IP addresses, to deliver TCP/IP stack configuration parameters such as the subnet mask and default router, and to provide other configuration information such as the addresses for printer, time and news servers.

&$ &�� $� �� "�� + �� + �� '��

8�� #$�

&�� &� �� " � �� " �� "��

#�) # ��)��"

%��%��# ��)��"�� %��H� ��"� ��



$))��!�� 1��$))��!��2��

��

#�� # ��

�� =

� ��

� #.�� :��

� $� �� "�� :��

%��#��

#&3 # ��&��3�� 9�� ,�� %��

#$ #�� $� �� "�� +�� +��

# ��*�� #*��

�� +��9��+� ��

��&�� )� ��

�� .�� .�� C��9��

#�J777 %�� ($��

�� .��

#�� &�� $� �� ,��

��&�� )� ��

#.��#�) �� .��# �� )��" �#�)�� ; � �� #�) �� %��#.��#�)�� #�)�

)�� "��"��

)�� )�� %�� ,�� H� �� +�� ?��%�� +� �� +��

8�� 8�� K� �� $��+!��+$$�+%�� +(�� (��

8(; 8� ��(�� ; 9�� 8� ��(�� ; 9�� F��G �� #�� #�� 9��

��& � ��&�� !#��&��

��$� � ��$� ��

%��?� ��

�$� � �� $� �� /�;��



$))��!�� 1��$))��!��2��

��

� ); � ��)�� ;�� %�� "� � �� ,��+ ��+ ��

� �� #�) �� %��H��

� ��(�� %�� +�� +��

��&�� )� ��

� �� &�� &�� "� ��

�&�� &��

�&��

Litespan Alcatel's access multiplexer that combines both traditional access multiplier and DSLAM capabilities. In the New Zealand environment it is not expected to be used as a DSLAM.

�� &�� )� ��

$��&�� $��&��

%��?��!��&�� &��+*�&�'�+�;��

$�� +��

��&�� )� ��

$� ��'�� +��"� ��!��

��&�� )� ��

$�� $�� "�� " �� 6�� %�� "� �� "� ��

!��"�� %�� " �� .�� " ��

��&�� )� ��

!��"# �� %��!��"# �� "�� + �� + � � �� "�+�� &0+&3&$�+�� +�� +$�� + ��



$))��!�� 1��$))��!��2��

��

!��"�� %�� " �� %!��

��&�� )� ��

;��)�� ;��)�� "��

��&�� )� ��

;�� 3�� %��?�� /��

;�� )��" �� #�)�� ;�� # �� &��*�� + ��

;��$� �� ;�� $� �� "�� "�� +��,�� +��,�� +��

��&�� )� ��

;�2* ;�� *��

%�� )��+�� (��+� �� +�� )�� .�� ;�2* �� ,�� )��,��

;�� ;��

��"��

��&�� )� ��

��"�� "��6��D��

��/ �� %��

%��/3� �� /$��

�� %�� + �� + �� +��+��

�&� ��&�� "�� ,��#��

�#� ��# �� "�� !8!�#�� L� ��#*/��



$))��!�� 1��$))��!��2��

��

�� $� �� + � � �� + ��

�E� �� E�� "�� "��

Policy Policies dictate how users, applications, and organisations can access and use network resources.

�� !��"# ��

�;! ��;��!��"� � � �.�� %��C�!��

�� K � �� +��

�� +��,�� "��

�� &�� )� ��

��(��" 0��

��&�� )� ��

�� "��

�� $� �� + � ��

��&�� )� ��

�� "�� %��%��"��

��&�� )� ��

��(��" ��

�� %�� +��

��&�� )� ��

�� (��

��&�� )� ��

�� %��%��

��&�� )� ��



$))��!�� 1��$))��!��2��

��

��%! �� %�� !��"

%�� .�� " �� .�� .�,�� .��C��

��%!!�� %!!��"��

%�� !��" �� %! �.�� ! � � �� "��

��&�� )� ��

�� &!� �� &�� !�� ' ��*��'*�� !��= � ��&!�� "��

��&�� )� ��

@�� + 9��+ ��"�� + � ��

@��#.�� &�� ,�� ,�� ?��

@�� @�� @��+� �� (��"��;��9��

�@�� "�� "��;��

*�&�'� Remote Authentication Dial In User Service

A protocol for carrying authentication, authorisation, and configuration information between a Network Access Server (e.g. BRAS terminating PPP sessions) which desires to authenticate its links and a shared Authentication Server (i.e. RADIUS or AAA Server).

*��.� ��&�� )� ��

*�&�'�� &�� )� ��

*�� (�� )� ��

*��%��)� � ��

�� MA77�� " ��

��&�� )� ��

*�� (�� #�� + ��"��

��&�� )� ��

*��(��"�� $�"�� " �� "��

��&�� )� ��

�� %!�� .��

�(� ��(�� #.�� %�� -��



$))��!�� 1��$))��!��2��

��

�� %�� "�� %�� !��" ��!� �� (��

�&/ ��&�� &/��L� �� L� ��#��

��2�� #�) �� %�� + � � � �� + �� + � � ;!�N ��

�� " � ��

��&�� )� ��

��"�� .��@�� ;!O �� *��+8��2��

�� &�� )� ��

�� &�� )� ��

�� ; ��&�� )� ��

�� C�� C��.��+� � ��&��

�� %�� ,��

��$� �� %��

�$� ��$� �� *�&�'��.�� !8!*��

�$� ��$�� %�.�$��

�;�� ; 9�� 3D�� 3� ��"�� /$��

��

��&�� )� ��

%�� %�� :�� ;�� ;��AA��

%��$� �� ,�� "�� +��+�� ,��

��&�� )� ��



$))��!�� 1��$))��!��2��

��

'&&� ' ��&�� +&��

0��+��+� �� %�� /$��

��&�� )� ��

' ��

'*� ' ��*�� %��

C�!$� �� $� ��C�!��

��&�� )� ��

C�� $� �� &��

3��83 3�� 8��

%��3��H�� 3��

��&�� )� ��

3� �� %�� H�� %�� ,�� ,��

��&�� )� ��

3��")��$� �� + ��+ � � � �� "��

�� +�� "�� "� �� 3)$ �� "��,�� "� ��

��&�� )� ��

3��"�� $� �� ,�� + �� &�� )� ��

3�&� 3� ��&��

�3��3��3� ��

/$�8�� /�� $��"�� 8��

�� /$� �� (6( �� + � �� .�� '&&�� #�� &�� )� ��

applied eaf ngn deployment v1 - massey university · pdf filefinancial authorization,...

Documents