Subclass 9	Subclass 10	Subclass 100
Distributed or remote access

System, method and article of manufacture for information service management in a hybrid communication system

6442547

Abstract

Telephone calls, data and other multimedia information is routed through a hybrid network system which includes transfer of information across the internet utilizing telephony routing information and internet protocol address information. The system includes an information services manager that provides data management and data communications between element managers and presentation managers. Information forward from the network element managers is utilized by the information services manager to provide information to network operators.

Claims

What is claimed is:

1. A method for information services management in a hybrid communication system, comprising the steps of:

a) separating system management information deemed more critical to monitoring and managing a hybrid communication system from information deemed less critical to monitoring and managing the hybrid communication system, wherein the system management information has been processed by a plurality of hybrid communication system components;

b) receiving the system management information;

c) selecting a portion of the system management information for forwarding to an operator of the system;

d) storing the system management information in databases; and

e) providing access to the system management information by a user.

2. A method as recited in claim 1, wherein the access to the system management information is provided by a presentation manager.

3. A method as recited in claim 1, wherein the system management information is received from an element manager.

4. A method as recited in claim 1, wherein the databases include operation and analytical distributed databases.

5. A method as recited in claim 1, wherein the databases include media and textual databases.

6. A method as recited in claim 1, wherein the databases provide procedures, policies, and computer training to network users.

7. A method as recited in claim 1, wherein at least one of the databases stores a manual having at least one of administrative information and maintenance information.

8. A method as recited in claim 1, further comprising the steps of analyzing the system management information to determine a status of the hybrid network for utilization during management of the hybrid network, and determining billing rates and discounts based on the status of the hybrid network.

9. A system for information services management in a hybrid communication system, comprising:

a) logic that separates system management information deemed more critical to monitoring and managing a hybrid communication system from information deemed less critical to monitoring and managing the hybrid communication system, wherein the system management information has been processed by a plurality of hybrid communication system components;

b) a processor that receives the system management information;

c) logic that selects a portion of the system management information for forwarding to an operator of the system;

d) logic that stores the system management information in databases; and

e) logic that provides access to the system management information by a user.

10. A system as recited in claim 9, wherein the access to the system management information is provided by a presentation manager.

11. A system as recited in claim 9, further comprising an element manager that provides the system management information to the system.

12. A system as recited in claim 9, wherein the databases include operation and analytical distributed databases.

13. A system as recited in claim 9, wherein the databases include media and textual databases.

14. A system as recited in claim 9, wherein the databases provide procedures, policies, and computer training to network users.

15. A computer program embodied on a computer readable medium for information services management in a hybrid communication system, comprising:

a) a code segment that separates system management information deemed more critical to monitoring and managing a hybrid communication system from information deemed less critical to monitoring and managing the hybrid communication system, wherein the system management information has been processed by a plurality of hybrid communication system components;

b) a code segment that receives system management information;

c) a code segment that selects a portion of the system management information for forwarding to an operator of the system;

d) a code segment that stores the system management information in databases; and

e) a code segment that provides access to the system management information by a user.

16. A computer program as recited in claim 15, wherein the access to the system management information is provided by a presentation manager.

17. A computer program as recited in claim 15, wherein the system management information is received from an element manager.

18. A computer program as recited in claim 15, wherein the databases include operation and analytical distributed databases.

19. A computer program as recited in claim 15, wherein the databases include media and textual databases.

20. A computer program as recited in claim 15, wherein the databases provide procedures, policies, and computer training to network users.

Description

FIELD OF THE INVENTION

The present invention relates to communication networks and more particularly to information service management in hybrid communication network system, including data and communications management.

BACKGROUND OF INVENTION

The current telecommunication service providers' networks reflect the architecture of the PSTN network as it has evolved over the last 100 years. This is largely based on circuit switched technologies. Initially, all telecommunication services were offered via a wired infrastructure. As the user-base increased and requirements changed over the last few decades, new types of services were created e.g. wireless PSTN, cable video, multi-service (PSTN, video, satellite). The networks that supported these services were created as parallel networks, along-side the existing PSTN network. As technologies matured, there was some convergence (e.g. they shared the same SONET backbone) in the network architecture. During the late 1980s, with the explosion of data networking and Internet, data networking networks like frame relay and ATM were developed, and later large internet based data networks were constructed in parallel with the existing PSTN infrastructure. These data networks again shared the PSTN infrastructure only at the SONET backbone layer. This state of current networks is called the existing "Core". Thus the "Core" network is a set of parallel networks; PSTN, wireless, satellite, cable, ATM, frame relay, IP. There is some interoperability between the services on these parallel network (e.g. PSTN, and wireless), but generally these networks are vertically integrated to provide distinct set of non-interoperable services.

SUMMARY OF INVENTION

According to a broad aspect of a preferred embodiment of the invention, telephone calls, data and other multimedia information is routed through a hybrid network system which includes transfer of information across the internet utilizing telephony routing information and internet protocol address information. The system includes an information services manager that provides data management and data communications between element managers and presentation managers. Information forward from the network element managers is utilized by the information services manager to provide information to network operators.

DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages are better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1A is a block diagram of an exemplary telecommunications system in accordance with a preferred embodiment;

FIG. 1B shows a block diagram of the Network Data Management in accordance with a preferred embodiment;

FIG. 1B-1 is a flowchart illustrating a Network Data Management process in accordance with a preferred embodiment;

FIG. 1C shows a block diagram of the Customer Interface Management Process in accordance with a preferred embodiment;

FIG. 1C-1 is a flowchart illustrating a Customer Interface Management Process in accordance with a preferred embodiment;

FIG. 1D shows a block diagram of the Customer Quality of Service Management Process in accordance with a preferred embodiment;

FIG. 1D-1 is a flowchart illustrating a Customer Quality of Service Management Process in accordance with a preferred embodiment;

FIG. 1E shows a block diagram of the Service Quality Management in accordance with a preferred embodiment;

FIG. 1E-1 is a flowchart illustrating a Service Quality Management Process in accordance with a preferred embodiment;

FIG. 1F shows a block diagram of the Problem Handling Process in accordance with a preferred embodiment;

FIG. 1F-1 is a flowchart illustrating a Problem Handling Management Process in accordance with a preferred embodiment;

FIG. 1G shows a block diagram of the Rating and Discounting Process in accordance with a preferred embodiment;

FIG. 1G-1 is a flowchart illustrating Rating and Discounting Process in accordance with a preferred embodiment;

FIG. 1H shows a block diagram of the Invoice and Collections Process in accordance with a preferred embodiment;

FIG. 1H-1 is a flowchart illustrating an Invoice and Collections Process in accordance with a preferred embodiment;

FIG. 2A is a flowchart showing illustrating media communication over a hybrid network in accordance with a preferred embodiment;

FIG. 2B is a block diagram of an exemplary computer system in accordance with a preferred embodiment;

FIG. 3 illustrates the CDR and PNR call record formats in accordance with a preferred embodiment;

FIGS. 4(A) and 4(B) collectively illustrate the ECDR and EPNR call record formats in accordance with a preferred embodiment;

FIG. 5 illustrates the OSR and POSR call record formats in accordance with a preferred embodiment;

FIGS. 6(A) and 6(B) collectively illustrate the EOSR and EPOSR call record formats in accordance with a preferred embodiment;

FIG. 7 illustrates the SER call record format in accordance with a preferred embodiment;

FIGS. 8(A) and 8(B) are control flow diagrams illustrating the conditions under which a switch uses the expanded record format in accordance with a preferred embodiment;

FIG. 9 is a control flow diagram illustrating the Change Time command in accordance with a preferred embodiment;

FIG. 10 is a control flow diagram illustrating the Change Daylight Savings Time command in accordance with a preferred embodiment;

FIG. 11 is a control flow diagram illustrating the Network Call Identifier (NCID) switch call processing in accordance with a preferred embodiment;

FIG. 12 is a control flow diagram illustrating the processing of a received Network Call Identifier in accordance with a preferred embodiment;

FIG. 13(A) is a control flow diagram illustrating the generation of a Network Call Identifier in accordance with a preferred embodiment;

FIG. 13(B) is a control flow diagram illustrating the addition of a Network Call Identifier to a call record in accordance with a preferred embodiment; and

FIG. 14 is a control flow diagram illustrating the transport of a call in accordance with a preferred embodiment;

FIG. 15A is a flowchart showing a Fault Management Process in accordance with a preferred embodiment of the present invention;

FIG. 15B is a block diagram showing a Fault Management component in accordance with a preferred embodiment of the present invention;

FIG. 16A is a flowchart showing a Proactive Threshold Management Process in accordance with a preferred embodiment of the present invention;

FIG. 16B is a flowchart showing a Network Sensing Process in accordance with one embodiment of the present invention;

FIG. 17 is a flowchart showing an Element Management Process in accordance with a preferred embodiment of the present invention;

FIG. 18 is a flowchart showing a three tiered customer support process in accordance with a preferred embodiment of the present invention;

FIG. 19 is a flowchart showing an integrated IP telephony process in accordance with a preferred embodiment of the present invention; and

FIG. 20 is a flowchart showing a Data Mining Process in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION

The following table is used to clarify terms used in the detailed description of the invention.

          AAA           Authentication, Authorization, Addressing
          ADSL          Asymmetric Digital Subscriber Line
          AIN           Advanced Intelligent Networks
          AMA           Automatic Message Accounting
          ATM           Asynchronous Transfer Mode
          BIM           Business Integration Methodology
          BSS           Business Support System
          CDR           Call Detail Record
          DTMF          DuaT-Tone Multi-Frequency
          GSM           Global System for Mobile Communications
          IN            Intelligent Network
          IP            Internet Protocol
          JPEP          Joint Picture Expert Group
          LMDS          Local Multi-Point Distribution Service
          MPEG          Moving Picture Expert Group
          NGN           Next Generation Network
          OSS           Operational Support Systems
          PCM           Pulse Code Modulation
          PSTN          Public Switched Telephone Network
          QoS           Quality of Service
          RAS           Remote Access Server
          SCE           Service Creation Environment
          sCP           Service Control Point
          SMDS          Switched Multi Megabit Data Service
          SSP           Service Switching Point
          SONET         Synchronous Optical Network
          STP           Service Transfer Point
          TCP           Transmission Control Protocol
          xDSL          Generic name for Digital Subscriber Line
          (D)WDM        (Dense) Wave Division Multiplexing

Data networks today rely heavily on shared medium, packet-based LAN technologies for both access and backbone connections. The use of packet switching systems, such as bridges and routers, to connect these LANs into global internets is now widespread. An internet router must be capable of processing packets based on many different protocols, including IP, IPX, DECNET, AppleTALK, OSI, SNA and others. The complexities of building networks capable of switching packets around the world using these different protocols is challenging to both vendors and users.

Standards-based LAN systems work reasonably well at transfer rates up to about 100 Mbps. At transfer rates above 100 Mbps, providing the processing power required by a packet switch interconnecting a group of networks becomes economically unrealistic for the performance levels desired. This inability to economically "scale up" performance is beginning to cause restrictions in some user's planned network expansions. Also, today's data networks do not provide network managers with enough control over bandwidth allocation and user access.

Tomorrow's networks are expected to support "multimedia" applications with their much greater bandwidth and real-time delivery requirements. The next generation networks should also have the ability to dynamically reconfigure the network so that it can guarantee a predetermined amount of bandwidth for the requested quality of service (QOS). This includes providing access, performance, fault tolerance and security between any specified set of end systems as directed by the network's manager. The concept is to provide network managers with complete "command and control" over the entire network's infrastructure--not just tell them when a failure has occurred.

A new set of technologies known as asynchronous transfer mode (ATM) may provide the best:, long-term solution for implementing the requirements of both private and public internets. ATM promises to provide a more economical and scalable set of technologies for implementing the ultra-high-performance information networks that will be required to provide the quality of service users will demand. Thus, over the next 20 years, the network infrastructure may change from packet-based standards to one based on ATM cell switching. While changes in the accompanying network will be dramatic, it would be desirable for users making the transition to be able to retain their most recent equipment investment.

Another expected change in tomorrow's networks is a change in data flow. Data flow in today's network typically follows the client-server computing model. This is where many clients are all transferring data into and out of one or more network servers. Clients do not normally talk to each other; they share data by using the server. While this type of data exchange will continue, much more of the information flow in tomorrow's networks will be peer-to-peer. Since the ultimate goal is a truly distributed computing environment where all systems act as both the client and server, more of the data flow will follow a peer-to-peer model. The network will be required to provide more direct access to all peers wishing to use high-performance backbone internets connecting, for example, the desktop computers.

The bulk of information transported in the future will be of digital origin. This digital information will require a great deal more bandwidth than today's separate voice, fax, and SNA networks which operate with acceptable performance using voice grade telephone lines. Voice will shrink as a percentage of total traffic, while other forms of information including image and video will greatly increase. Even when compressing is available, the bandwidth requirements for both inside and outside building networks will need to be greatly expanded.

Text files and images can be sent over existing packet-based networks because the delivery of this information is not time critical. The new traffic (voice and video) is delivery time sensitive--variable or excessive latency will degrade the quality of service and can render this information worthless.

The usefulness of packet switching networks for the transmission of digital information, particularly burst type information, has long been recognized. Such networks are generally point-to-point in nature in that a packet from a single source is directed to a single destination by an address attached to the packet. The network responds to the packet address by connecting the packet to the appropriate destination.

Packet switching networks are also used which combine burst type data with the more continuous types of information such as voice, high quality audio, and motion video. Commercialization of voice, video and audio transmission makes it desirable to be able to connect packets to multiple destinations, called packet broadcasting. For example, a broadcast video service such as pay-per-view television involves a single source of video packets, each of which is directed to multiple video receivers. Similarly, conferencing capabilities for voice communication also require single source to multiple destination transmission.

One prior packet broadcast arrangement comprises a network consisting of a packet duplication arrangement followed by a packet routing arrangement. As a broadcast packet enters this network, packet copies are made in the packet duplicating arrangement until as many copies exist as there are destinations for the packet. A translation table look up is then performed at the duplication arrangement outputs for each of the packet copies to provide a different, single destination address for each copy. All of the packet copies with their new packet addresses are then applied to the packet routing arrangement, which connects them to the appropriate network output ports.

In packet switching networks, packets in the form of units of data are transmitted from a source--such as a user terminal, computer, application program within a computer, or other data handling or data communication device--to a destination, which may be simply another data handling or data communication device of the same character. The devices themselves typically are referred to as users, in the context of the network. Blocks or frames of data are transmitted over a link along a path between nodes of the network. Each block consists of a packet together with control information in the form of a header and a trailer which are added to the packet as it exits the respective node. The header typically contains, in addition to the destination address field, a number of subfields such as operation code, source address, sequence number, and length code. The trailer is typically a technique for generating redundancy checks, such as a cyclic redundancy code for detecting errors. At the other end of the link, the receiving node strips off the control information, performs the required synchronization and error detection, and reinserts the control information onto the departing packet.

Packet switching arose, in part, to fulfill the need for low cost data communications in networks developed to allow access to host computers. Special purpose computers designated as communication processors have been developed to offload the communication handling tasks which were formerly required of the host. The communication processor is adapted to interface with the host and to route packets along the network; consequently, such a processor is often simply called a packet switch. Data concentrators have also been developed to interface with hosts and to route packets along the network. In essence, data concentrators serve to switch a number of lightly used links onto a smaller number of more heavily used links. They are often used in conjunction with, and ahead of, the packet switch.

In virtual circuit (VC) or connection-oriented transmission, packet-switched data transmission is accomplished via predetermined end-to-end paths through the network, in which user packets associated with a great number of users share link and switch facilities as the packets travel over the network. The packets may require storage at nodes between transmission links of the network until they may be forwarded along the respective outgoing link for the overall path. In connectionless transmission, another mode of packet-switched data transmission, no initial connection is required for a data path through the network. In this mode, individual datagrams carrying a destination address are routed through the network from source to destination via intermediate nodes, and do not necessarily arrive in the order in which they were transmitted.

The widely-used Telenet public packet switching network routes data using a two-level hierarchy. The hierarchy comprises a long distance-spanning backbone network with a multiplicity of nodes or hubs, each of which utilizes a cluster of backbone switches; and smaller geographic area networks with backbone trunks, access lines and clustered lower level switches connected to each hub. Packet-switched data is transmitted through the network via VCs, using CCITT (International Telegraph and Telephone Consultative Committee of the International Telecommunications Union) X.75 protocol, which is a compatible enhancement of X.25 protocol.

For a communication session to proceed between the parties to a connection, it is essential that data be presented in a form that can be recognized and manipulated. The sequence of required tasks at each end, such as the format of the data delivered to a party, the rate of delivery of the data, and resequencing of packets received out of order, is generally handled in an organized manner using layered communication architectures. Such architectures address the two portions of the communications problem, one being that the delivery of data by an end user to the communication network should be such that the data arriving at the destination is correct and timely, and the other being that the delivered data must be recognizable and in proper form for use. These two portions are handled by protocols, or standard conventions for communication intelligently, the first by network protocols and the second by higher level protocols. Each of these protocols has a series of layers. Examples of layered architectures include the Systems Network Architecture (SNA) developed by IBM, and the subsequently developed Open Systems Interconnection (OSI) reference model. The latter has seven layers, three of which are network services oriented including physical, data link, and network layers, and the other four providing services to the end user by means of transport, session, presentation, and application layers, from lowest to highest layer.

X.25 is an interface organized as a three-layered architecture for connecting data terminals, computers, and other user systems or devices, generally refereed to as data terminal equipment (DTE), to a packet-switched network through data circuit terminating equipment (DCE) utilized to control the DTE's access to the network. The three layers of the X.25 interface architecture are the physical level, the frame level and the packet level. Although data communication between DCEs of the network is routinely handled by the network operator typically using techniques other than X.25, communication between the individual user system and the respective DCE with which it interfaces to the network is governed by the X.25 or similar protocol. In essence, X.25 establishes procedures for congestion control among users, as well as call setup (or connect) and call clearing (or disconnect) for individual users, handling of errors, and various other packet transmission services within the DTE-DCE interface.

X.25 is employed for virtual circuit (VC) connections, including the call setup, data transfer, and call clearing phases. Call setup between DTEs connected to the network is established by one DTE issuing an X.25 call-request packet to the related DCE, the packet containing the channel number for the logical connections, the calling and called DTE addresses, parameters specifying the call characteristics, and the data. The destination DCE issues an incoming call packet, which is of the same general format as the call-request packet, to the destination DTE, the latter replying with a call-accepted packet. In response, the calling DCE issues a call-connected packet to its related DTE. At that point the call is established and the data transfer phase may begin by delivery of data packets. When the call is compared, i.e., the session is to end, a call-clearing procedure is initiated.

Prospective routing paths in the network are initially determined by a network control center, which then transmits these predetermined paths to the backbone switches as routing tables consisting of primary and secondary choices of available links from each hub. The secondary choices are viable only in the event of primary link failures, and the specific secondary link selection is a local decision at the respective hub based principally on current or recent traffic congestion patterns. The unavailability of an outgoing link from a hub at the time of the call setup effects a clearing back of the VC for the sought call to the preceding hub. An alternative link is then selected by that hub, or, if none is available there, the VC circuit is again cleared back to the next preceding hub, and so forth, until an available path is uncovered from the routing tables. Messages concerning link and/or hub failures are communicated immediately to the network control center, and that information is dispatched to the rest of the network by the center.

In typical present-day concentrators and packet switches, the data processing devices reside in a plurality of cards or boards containing printed circuits or integrated circuits for performing the various functions of the respective device in combination with the system software. Typically, the cards are inserted into designated slots in cages within a console, with backplane access to a data bus for communication with one another or to other devices in the network. The VME bus is presently the most popular 16/32-bit backplane bus. References from time to time herein to cards or boards will be understood to mean the various devices embodied in such cards or boards.

Many public data networks (PDNs) offer little or no security for communications between users and hosts or other data processing devices within the network, in keeping with the "public purpose" of the network and the desire for accessibility by a large number of actual and prospective users. Where restrictions on access are necessary or desirable, it is customary to assign each authorized user an identification (ID) number or a password, or both, which must be used to gain access to the host. More elaborate security measures are necessary where access may be had to highly confidential data.

Some data communication networks involve a variety of different customers each of whom makes available a host and one or more databases to its users, and may place a level of security on its database which differs from the level placed by other customers on their respective hosts and databases. In those instances, it is customary to make the host responsible for security and access to itself and its associated database. Thus, a user might have access to certain destinations in the network without restriction, but no access to other destinations.

Market Drivers

According to Yankee Group Research, network management costs continue to increase, with network managers spending an average of 45 percent of their budget on ongoing network management, 20 percent on equipment, and 35 percent on network transport services. It is a constant battle to reduce these costs yet somehow improve overall service to their customers. Reducing overall network management costs can be very difficult in today's business environment. Networks continue to become more complex, with more and more demands being placed on the network managers and planners. For example, the exponential growth of remote access has made their jobs more difficult, as the requirement to establish and manage connections for remote offices and telecommuters is often required without additional personnel or budget resources. Unfortunately, network managers and planners spend so much time in "firefighting" mode, trying to support their complex networks, that very little time is actually spent planning for network growth and enhancements. Combined with this is the fact that it is becoming difficult to keep highly skilled employees given the demand for certain skills in the marketplace, and the premiums that will be paid for those skills. So, what is a network manager to do? More and more, they are looking outside for help.

The market for customer network management services is generally referred to as Managed Networked Services (MNS). Yankee Group estimates this market will estimated to grow from $3B to 9B within the next three years. MNS became the focus of service providers in 1995 as they saw revenues for frame relay network services double for two years in a row. What began as a way to boost the popularity of frame relay services by offering to lease and manage routers has blossomed into a diverse set of services that are now closer to those associated with outsourcing.

Yankee Group research shows that 37 percent of Fortune 1000 managers are already outsourcing or plan to outsource their ongoing network operations management. In addition, it is the communications provider that is thought of as the most likely provider for one-stop shopping services.

The present invention's overall approach to implementing the NM(MNS market offering is two fold. The current opportunity that presents itself is MNS. While this market opportunity for clients is large, they need assistance in understanding data network management--for years they have been solely focused on voice. Additionally, they need to move into this market quickly in order to maintain and grow revenue. To this end, the present invention includes a set of assets consisting primarily of job aids and software that can greatly reduce our clients lead time for service implementation.

Secondly, the present invention assists service providers by providing them the tools to better manage their carrier data networks--the packet switched networks of the future. The present invention significantly enhances and scales MNS assets to address carrier network management in a data networking world. This solution template enables the convergence of circuit and packet switching network control centers and workforces.

The present invention's market offering suggests companies take a graduated approach to delivering MNS. One end of the continuum consists of MNS for current network services, including leased lines, frame relay, and X.25. On the far end is outsourced MNS characterized by long-term contracts, involving hundreds of millions of dollars. The NM/MNS market offering is proposing our clients go beyond the management of the router and the WAN, and into the world of the local area network (LAN), even as far as the desktop and business applications. Service providers have been intimidated by these propositions in the past, since management of the LAN and its equipment and applications has clearly not been their forte.

It is hard to describe a typical MNS engagement because this is such a new. There are three "entry points" in which the present invention can become involved in helping our companies to move into the MNS market:

Business Strategy--Companies may look to the present invention for assistance in creating a business strategy for entering the MNS market. Typically, this type of engagement will defines a company's target market for MNS (small, mid-market, large) and defines the service offerings that are best suited for the company to offer. These engagements will be followed by analysis, design and implementation projects.

Requirements Analysis--Companies may already have developed a concrete business strategy that defines which services they will offer within markets. In this case, the present invention's work will begin by helping define the company's network environment requirements. This work will be followed by design and implementation projects.

Design and Implementation--Companies may be ready to move to the design and implementation phases of creating an MNS capability. Generally, the present invention will confirm that their network meets the requirements to provide the service, then assist the client in the designing and implementing an appropriate solution suite.

In an effort to clearly communicate exactly how we define NM/MNS we have created an online catalog of services. The present invention's solution is a continuous cycle that begins with the four major processes associated with NM/MNS. These processes drive the technology and the people components of the solution. Within each of these processes are a number of core functions and sub-functions. The MNS Online Catalog contains all of this information, including the supporting process, technology and organizational solutions for each function.

Our solution is called the Managed Networked Services Integrated Solution (MNSIS) and has been developed using an approach which integrates Process, Technology, and People considerations.

Process

At the highest level, there are four major processes that must be performed to manage any network:

Service Planning

Managing Change

Operations Management

Service Management

Each process should be performed in order to provide a complete NM/MNS solution. As mentioned above, each process has a number of associated functions and sub-functions that provide the complete picture of the process. The major functions associated with each process are as follows.

Technology

The main goal of the technology solution is to provide access to network information to make informed decisions. The present invention includes three layers of management: element management, information services management and presentation management. Every action starts with an incident. Processing is tailored to handling the incident with technology that responds to the unique characteristics of each incident.

Element Manager

The element manager communicates with the network elements to receive alarms and alerts through trapping and polling techniques. The element manager is the layer where the primary data reduction functions reside. At this layer, events received at the element manager will be filtered, aggregated and correlated to further isolate problems within the network. Information that is deemed critical to monitor and manage the network is translated into a standard object format and forwarded to the Information Services Manager. An element manager can be, but is not necessarily, software which adheres to open standards such as the Simple Network Management Protocol (SNMP) and the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA).

Information Services Manager

The information services manager provides the data management and data communications between element managers and presentation managers. All information forwarded from the element managers is utilized by the information services manager to provide information to the network operators. The information services manager adheres to CORBA standards to provide ubiquitous information access via an Object Request Broker (ORB). The ORB allows the information services manager to share management information stored in distributed databases.

The information services manager stores critical management information into operational (real-time) and analytical (historical) distributed databases. These databases provide common data storage so that new products can be easily inserted into the management environment. For example, if an event is received at an element manager that is deemed critical to display to a network user, the information services manager will store a copy of the alarm in the operational database and then forward the alarm to the appropriate network operator.

Media and textual databases are also provided by the information services manager. The databases includes online manuals for administrative purposes, as well as for the maintenance specialists to access element specific information. The databases also provide procedures, policies and computer based training to network users.

The information services manager provides requested information (real-time and historical) to the network users via the presentation manager.

Presentation Manager

The presentation manager performs the function its name implies: the presentation of the information to an end user. Because different locations and job functions require access to different types of information, there are at least two types of display methods. The first is for graphic intensive presentations and the second is for nomadic use, such as field technicians. The first environment requires a graphic intensive display, such as those provided by X-Windows/MOTIF. The second environment is potentially bandwidth poor where dial-up or wireless access may be used along with more traditional LAN access. This is also where browser technology is employed.

People

The people vision for the NM/MNS include an organization model for customer service support, the corresponding roles and responsibilities for this organization model and a conceptual design for workforce transformation to packet switching.

Customer Service Support

Customer service support provides a single point of contact that is customer focused. This single point of contact provides technical expertise in resolving customer incidents, troubles and requests. Generally a three tiered support structure is optimal for satisfying customer service needs. Each tier, or level, possesses an increasing level of skill, with tasks and responsibilities distributed accordingly. Such a structure is as follows:

Tier 1--typically has a broad set of technical skills and is the first level of support to the customer. Typically this group is responsible for resolving 60-70 percent of the opened problems.

Tier 2--are technical experts and field support personnel who may specialize in specific areas. Typically this group is responsible for resolving 30-40 percent of the opened problems.

Tier 3--are considered solution experts and often consist of hardware vendors, software vendors or custom application development/maintenance teams (in-depth skills needed to investigate and resolve difficult problems within their area of expertise). They are the last resort for solving the most difficult problems. Typically this group is responsible for resolving 5 percent or fewer of the opened problems.

The above model is generally referred to as the Skilled Model because personnel at all three tiers are highly skilled. This model generally creates a high percentage of calls resolved on the first call. Other approaches include:

Functional Model

In this model, users are requested to contact different areas (via VRU) depending on the nature of the incident. Calls are routed to the customer support representative best able to handle the call. This model can easily be coupled with the Skilled Model, and has been at previous client engagements.

Bypass Model

In this model, Tier 1 only logs calls, they do not resolve calls. One advantage of this model is that skilled resources don't have to waste time logging calls.

Software and Assets

Managed Networked Services Integrated Solution--The integrated network management solution template consists of a suite of best of breed third party software products that automate problem diagnosis, notification, custom-developed reporting, and IP services monitoring. This solution template is a great first step in realizing our technology solution vision.

Web-Based SLA Reporting Tool--is a browser based tool that provides the personalized SLA reports to customers in both a template and ad-hoc format.

Data Mining Demonstration--Provides the capability to analyze network management data looking for patterns and correlations across multiple dimensions. Build models of the behavior of the data in order to predict future growth or problems and facilitate managing the network in a proactive, yet cost-effective manner.

Customer to Event Mapping Module--Add-on module to the Managed Networked Services Integrated Solution which maps network element events, to service offerings, to customers. This tool allows the Customer Service Representative to proactively address network outages with customers.

Process Definitions and Functions

Service Planning

Service Planning includes both the strategic and tactical planning required to manage distributed environments effectively. Although most planning typically occurs during rollout of the system, certain planning activities must otherwise take place. Service Planning ensures that change can be successfully controlled and implemented.

Service Management Planning

Operations Management Planning

Managing Change Planning

Strategic Planning

Managing Change

Includes processes and procedures for handling necessary changes to systems or the organization in a distributed environment.

Change Control

Testing

Implementing

Software Distribution

Operations Management

Systems Management consists of the day-to-day operational functions required to maintain the system (e.g. fault detection/correction, security management and performance management).

Production Control

Monitoring and Control

Fault Management

Security Management

Service Management

Service Management controls the overall service to the users of the system. It isolates users from how the system is managed, and ensures that users receive the quality support services they need to carry out their daily business activities.

SLA/OLA Management

Help Desk

Quality Management

Billing and Accounting

The present invention includes a system, method, and article of manufacture for providing a hybrid circuit switched/packet switched network. This hybrid network is used as a transitioning network to transition from old "Core" network architectures to "New Core" networks. In the present description, the details of the NGN transitioning network will first be set forth after which details relating to specific billing aspects of the present invention will be described.

PSTN, wireless, and cable networks have continued to grow at their organic rates determined by the growth of the vertical services they were providing. In the beginning, the data networks used a small portion of the backbone SONET bandwidth, while PSTN was still the dominant bandwidth user. Due to the exponential growth in IP traffic, the IP based data networks are soon slated to utilize more bandwidth than the PSTN. Also huge technical advances in packet technologies have made it possible to carry traditional voice over IP networks. This has started a move towards the "Next Generation Network (NGN)" where there will be more sharing of common network infrastructure to provide services, and these services will start to become more interoperable. The main thrust of technologies in the "NGN" will be to provide interoperability between the new packet based infrastructure and existing legacy infrastructures. Due to the large investments made in the legacy infrastructure, they will continue to exist for some time, but most new innovations will occur on the packet based infrastructure. Slowly, the parallel networks that were created to serve distinct services will merge to use a common packet based backbone and only differ in how access is provided (wire-line, wireless, cable, satellite). The "NGN" is a transition network which will exist during the transformation from the current "Core" to the "New Core".

As packet technologies continue to develop rapidly, it will be possible to support what was once a distinct set of services (voice, video, wireless) on separate parallel networks, on one integrated packet based network. There will still be separate access technologies (wireless, satellite, cable, wire-line) to access these services, but the access networks will all use a common "New Core" network and its capabilities. The services will be interoperable across various access technologies, and users will freely use services that cross many access technologies, e.g. wireless to cable phone services, web browsing from wireless devices etc.

The present invention maps a course for the network evolution from circuit to packet switched technology using a migratory approach in which the network becomes a hybrid circuit and packet topology over a 3 to 7 year period.

Next, the network architecture for the wire-line network as it transforms from "Core" to "NGN" to "New Core" will be described. Followed by architecture for cable, wireless and satellite based access networks.

The Wire-line Network Architecture

"Core" Network Architecture

The current wire-line "Core" network consists of parallel PSTN, SMDS, ATM, Frame-Relay, B/PRI and IP networks. The PSTN network has been evolving over the last century and is a mix of old and new circuit switched technologies. The PSTN network mainly provides point-to-point interactive two-way voice communication services. The service set has evolved to include many intelligent network (IN) service features. During the late 1980s, Advanced Intelligent Networks (AIN) emerged as the architecture to support new voice based services on the PSTN infrastructure.

IN requirements and architecture in the current "Core"

The major IN requirements include session establishment, advanced call processing, call routing and call treatment (network messages and call termination). Examples of applications and features are the CLASS family of services (Call waiting, Call forwarding, Conference calling, Call rejection), enhanced call routing, Number Portability, Calling Card Services, and Audio delivered Information Services (e.g. travel, stocks and weather).

These IN capabilities are enabled by devices such as SCP, STP, SSP and EIP in the AIN environment. These devices participate in the execution and completion of an IN service. In order to develop, test and launch new IN service applications on the above mentioned components, service providers deploy Service Creation Environment (SCE) platforms, which provide an environment to quickly create new IN services. These SCE platforms are closely tied to the runtime environment and therefore with very few exceptions become a major undertaking and a complex coordination effort to launch a new or modified IN service in the "Core" network environment.

Data networks in the "Core"

While the PSTN was growing in feature functionality as well as traffic demand, new data networks have been created to support the inter-networking of computing devices. These data networks provide interconnection to geographically dispersed computing devices at varying levels of transmission bandwidth (e.g. 56/64K, T-1/E-1, T-3/E-3, OC-3/STM-1). The data networks consist of many technologies e.g. SMDS, ATM, frame-relay and IP. In some cases, these data networks themselves are parallel networks, in other cases, they share a common technology in the backbone (e.g. ATM can be the backbone for frame relay and IP data networks). These data networks share the same SONET based backbone with the PSTN network. The services on the PSTN and the data networks are very distinct and non-interoperable (example: voice versus web access).

With the rapid explosion of the Internet, and innovation in packet based technologies, the IP based data network has become the dominant network in terms of user traffic, and its growth is slated to continue exponentially. This phenomenon has created a dilemma for traffic planners and engineers of the Core network. They have seen traffic grow on the access portions of their networks (PSTN) but have realized very little financial benefits from this usage because third party service providers have been the termination point of these internet data users. The incumbents have began to devise intelligent network solutions for this data traffic (example RAS with SS7 gateway) in order to solve two major challenges: 1) off loading data traffic from the voice infrastructure to alleviate the congestion issues that face traditional voice customers and 2) collecting revenues from the third party data services providers (ISP's) for access and routing callers to their Points Of Presence.

Due to the high growth in IP and other data services, many new service providers have emerged that are building only IP based data networks, and provide only IP based data services. Their business strategy is to continue to ride the technological innovation of IP and packet based technologies and build complete suites of services on a packet based infrastructure. Because they are investing in only one form of network (as opposed to many parallel networks ), their unit cost of services is low, they are not encumbered by legacy networks and systems, and they can provide cheaper and better services to customers; hence they pose a significant threat to incumbent telecom service providers.

"Next Generation Network" Architecture

As packet based technologies continue to develop and provide the services that were only available on other networks (e.g. PSTN, cable), and new (green field) service providers continue to exploit their advantage, it has become necessary for many incumbent service providers to transition their "Core" network to the "Next Generation Network", where they can share the rapid technical advantages of packet technologies, and improve their cost structure, and at the same time offer new services on the "Next Generation Network".

New IP based services in the "NGN"

While there are components in the NGN that ensure interoperability between "NGN" and PSTN, there are also a huge new set of new services that are built entirely on the NGN components which is provide feature rich multimedia (voice, video, data) based communication services as well as enabling many E-Commerce services enabled by IP technologies. These components (described later in detail) include directories, policies, user authentication, registration, and encryption. These components enable services like integrated messaging, multimedia conversations, on-demand multi-point conference, enhanced security & authentication, various classes of media transport services, numerous automations in electronic internet commerce activities e.g. banking, shopping, customer care, education, etc. As the NGN matures third party value added service providers will develop IP based services that will combine applications such as electronic commerce (procurement, warehousing, distribution and fulfillment) as well as online banking to present the consumer with an integrated boundless shopping experience.

Growth of bandwidth in the "NGN"

In addition to new service features, the NGN also employs the use of new wire-line broadband access technologies, notably xDSL. Traditional wire-line access technologies will continue to be deployed at higher and higher speeds; wire-line access will move from predominantly T-1 speeds to T-3 and OC-n speeds. These new broadband access technologies will increase the need for higher bandwidth in "NGN" core. The "NGN" core continues to use a SONET backbone, but will gradually move to using (D)WDM technologies to provide the bandwidth required to support broadband access.

New and emerging technologies such as Giga-Bit Ethernet and Wire Speed IP may find their way to the network backbone, but not until Giga-bit Ethernet technology matures to handle a wide array of network services such as connection oriented circuit emulation. The use of Wire Speed IP technology is suitable for an enterprise network but lacks the robustness and scalability needed for carrier grade backbones. For this reason, there will always be a need for ATM in the backbone.

The architecture in the "NGN" provides seamless interoperability of services between the packet based network and the traditional PSTN. New "NGN" packet based capabilities will be developed to support AIN type features, while inter-operating with legacy PSTN/SS7/AIN. Large scale innovation in the IP based IN type capabilities (e.g. global number transparency, utilization of web based information, rich media communications) will create new services for IP enabled communication devices. Innovations on the PSTN will occur slowly, and may be restricted to maintaining interoperability of legacy PSTN with "NGN". In many cases, legacy PSTN components (e.g. SSP, SCP) will continue to evolve so that they can use common IP based packet switching technologies (e.g. IP, TCP, UDP), as opposed to using existing circuit switched technologies (e.g. MTP).

IN requirements and architecture in the Next Generation Network (NGN)

Given the huge revenues and global nature of PSTN services, as well as their use of SS7 and AIN technologies, components that allow interoperability between "NGN" and PSTN will need to be developed. These will include IP/PSTN Gateways, IP/PSTN address translators, EP/SS7 Gateways, IP enabled SSP's, and IP based Intelligent Peripherals. In addition to IN enablers, new components (as will be describe later) with features like directories, policies, user authentication, registration, session encryption, etc. will also be developed to enhance the IN capabilities. The NGN-IN enablers will provide the next level of intelligence in order to address communication over mixed media types, control of multiple session characteristics, collaborative communications needs, ubiquitous network access, "any to any" communications, and multimedia delivered information services. Note that these "NGN" components will continue to evolve to provide similar and enhanced capabilities in the "New Core".

The following provides a description of new components in the "NGN" and the "New Core" that provide enhanced IP based services. The Intelligent IP (I.sup.2 P) Network enablers are categorized as follows:

Session Control (Bandwidth, Switching and Routing)

Media Control (Call Treatment such as media conversion)

Policy Management (Directory, Access control, Security)

Bandwidth Management (Transport and real time restoration)

The components for the "NGN" are described as individual functional units but may be combined for practicality on individual network devices as the requirements dictate. These components have been designed to operate in a distributed network environment to increase the flexibility of the NGN and New Core. The architecture provides a robust, secure and isolated messaging infrastructure for delivering control plane information to these devices.

This infrastructure includes a well defined message set for accessing the functions that are provided by these components and data that resides in the rules database. The control plane architecture is efficient and has a unique mechanism for sharing service, user and control data without duplication. This permits mobile NGN service users to maintain the same experience and have access to the same information regardless of where or how they access the network.

Example: Assuming a US based NGN service user was roaming in Europe and wanted to access the network but has the use of specific calling information stored in his profile database in the US, how would such a challenge be overcome without replicating the user's data onto every rules database on the NGN to ensure that the user would not be denied access to features and services which the user typically subscribed. Obviously, storing or replicating this data and then managing synchronicity over a worldwide network would be process intensive, costly and cumbersome. This intelligent network architecture addresses these issues efficiently with mechanisms that make remote data available locally for the duration of a session and then caches the information in short term non-volatile memory not in the foreign rules database server. In other words although a user's profile may be physically stored in a Rules database in the United States, the user may access the network from Europe and be automatically granted access to the specific services and features that normally would be available during his US service experience. The remote session controller in Europe would communicate with the cross network location register and rules database server to identify the subscriber's "home" rules database in order to collect the policies and profile of the subscriber for use in Europe; this is done by using the inter device message sets (command and control ) over the control plane sub network. Unlike other mechanisms often employed, this mechanism does not replicate this information onto the local (European) rules database, making long term control data management predictable. The design is CORBA compliant and therefore can be interconnected with other standards based networks.

Rules Database server

Determines Subscriber Profile

Session requirements such as Bandwidth, Quality Of Service, Class Of Service

Routing preferences based on Priority, Cost, Termination Location

Media and Application requirements (Voice Telephone to Video Telephone, Multi-point, text to speech, Fax to E-mail etc.)

Content Separation (Example: Tells the intelligent peripheral and protocol converter to separate the Audio stream from the data and video stream on an H.32x call; It may also instruct the protocol converter to process the stream so as to enable this audio stream to be fed to a destination which supports traditional analog voice hence the G.728/9 content from the H.32x session would be converted first to AD/PCM and then sent to a Class 5 circuit based switch and terminated on a circuit switched SS7 network POTS line)

Access Device (Session Control)

Provides connectivity and session termination from customer premises to the NGN

Acts as the hub for the various applications (Video, Voice, Fax, Web Data, Unified Messaging)

Provides systems management and reporting functions

May provide application multiplexing (allowing simultaneous multi application access)

Intelligent Peripheral (Media Control)

Provides services such as DTMF parsing, Voice prompting, Messaging, Speech recognition, Text to Speech, Text to Fax, etc.

Protocol Conversion (Policy Management)

Receives session requirements from Rules database

Selects and executes required filters to enable activation, processing and tear-down of sessions

Interfaces with existing CORE network to process information across NGN/Extended CORE

Filters and Converts signals from SS7/ISDN to TCP/IP /H.323

Converts Signaling data from one format to another (example: G.728/9 to AD/PCM or Vocaltec to Vienna Systems, etc.)

Network Access Control Point (Session Control)

Similar to a switching node on an SS7 circuit switched network.

First or Last Access Point in the network

Provides actual call/session handling, routing and processing based on instructions from the Rules Database server

Session Manager/Event Logger (Session Control)

This process or application is critical since it is the "glue" between the end user application and the communications network. It is responsible for collection and distribution of end-user session preferences, application requirements, access device capability and accounting policy information to the required "IN enabling" components. In summary its main functions are to:

Create the AMA /CDR and other usage records

Interfaces external 3.sup.rd party Network Gateways.

Liase with Clearing Houses and Cross Network Location Registers

Feeds the Financial Infrastructure

Cross Network (Roaming) Location Register (Policy Management)

Similar to the Home location register in the wireless/cellular telephony world. This functional component provides the required policies governing users who access third party networks and cross geographical boundaries. It keeps in constant contact with other cross network location registers of the geographically dispersed but inter-connected networks, exchanging accounting, service feature profile and control data for local and roaming subscribers.

"New Core" Network Architecture

Most of the attributes of the "New Core" will already be in place as part of "NGN". These include all intelligent components of the packet based "NGN" described above. The emergence of "New Core" signals the retirement of legacy PSTN network infrastructure. The traditional PSTN may never get removed from the public network, it may continue to be available as a universally accessible telecommunication service, highly subsidized and regulated by government agencies (AMTRAK model). But for the purposes for business and technical innovation, traditional PSTN network will largely become irrelevant.

As the PSTN based access methods go away, entirely IP based access methods will emerge in the "New Core", where all end devices connected to the "New Core" are IP enabled. All existing methods of wire-line based access (xDSL, T-1, T-3, fiber) will continue to provide access to IP based services over the "New Core". New access technologies (e.g. power-line) will emerge, but will still use the same packet based capabilities in the "New Core".

The trends observed in the "NGN" will continue with increased broadband access. Other access methods (cable, satellite, wireless) will also complete their transformation to the "New Core". These will all become IP enabled access technologies that will use the "New Core" for complete set of services, thus really providing seamless services across many different access technologies.

The Wireless Data Network Architecture

The current wireless "Core" network consists of wireless based access and roaming capabilities that inter-operate with wire-line PSTN "Core" infrastructure to provide interoperable PSTN services. As the PSTN migrates to "NGN" and "New Core", the wireless PSTN access infrastructure will also migrate to connect to "NGN" and "New Core" to provide wireless PSTN access services while utilizing new capabilities in the "NGN" and the "New Core". There will also be innovations in the wireless end-devices such that they will become IP enabled, and will thus allow a broad range of innovations by allowing mobility to the wire-line IP based service capabilities (e.g. web browsing, e-mail etc.). These wireless access methods to the "New Core" will be restricted to lower speeds due to the legacy nature of this wireless infrastructure while new broadband wireless access may emerge to provide a new set of IP enabled wireless devices that can provide broadband services over wireless/mobile devices. In Europe, significant improvements in technologies such as GSM have provided insight into some NGN and New CORE capabilities such as 300 Kilobits of access bandwidth to deliver information to hand-held wireless devices. The potential of such capabilities coupled with the traditional strengths of wireless communications such as roaming and error handling enabled by digitization, at this stage seems limitless when aggregated with the intelligence of the NGN and New CORE backbone.

LMDS is an emerging technology in the local high speed wire-less access, which utilizes the 25-35 GHz microwave spectrum for point to point and point to multi-point communications. The end users either share an antenna connected to a digital receiver which is connected to a channel bank. The application server be it voice (PBX), video (CODEC), or Data (Router or Switch) interfaces with the NGN via the channel bank. A session originates from the application which interacts with the server to request authentication (AAA), then a session is established between originator and destination application by routing the call through the NGN components such as Gateways and Switches.

The Emerging Satellite Data Network Architecture

In addition to the wireless access infrastructure, new service providers have emerged that are trying to use low earth orbiting satellites (LEOS) to build a new access as well as backbone network infrastructure. The earlier version of these networks were built using traditional PSTN service model, hence they lack the bandwidth scalability for data services. In the "New Core", these will migrate to new packet switched based broadband LEO infrastructure, which will provide both high speed access as well as high speed backbone in the packet based "NGN" and "New Core". A satellite based broadband access mechanism will also be very suitable for multi-point services that will be developed on the "New Core".

The Cable Network Architecture

Cable networks were developed for mainly broadband broadcast of analog video entertainment services. The current "Core" cable infrastructure is suitable to serve one way video broadcast. Cable service providers are now upgrading their cable infrastructure to support high speed internet access. Thus in the "NGN" scenario for cable networks, cable will provide a new access mechanism for IP services, while simultaneously transport video content using the current video broadcast technology. Thus the IP enabled devices attached to the "NGN" cable infrastructure can take advantage of all the new components and capabilities described in the wire-line "NGN". This will enable seam-less services between devices that are accessing the "NGN" via a wire-line or cable infrastructures. This "NGN" cable infrastructure can provide IP based telephony services using the same components of the wire-line "NGN" that provide IP telephony to wire-line IP devices.

The digital network segment that interfaces with the "NGN" comprises of a coaxial cable local loop which is connected to a cable data modulator running QAM/DPSK protocols. The coaxial loop is terminated at the customer premise by an Ethernet cable modem which delivers the IP Tone to the applications (Voice, Video, Data) that may reside on a PC or application server. The cable modems used provide users and applications with a wide range of bandwidth options from 2 to 10 Mbits per second depending on configuration and choice of equipment vendor.

With the evolution of the "New Core" in the wire-line, the cable will continue to provide another broadband access mechanism for IP based services. As the "New Core" matures and enhances in capabilities (probably 10 years away), such that it can provide high speed real-time video content (to provide same quality as cable), it can be envisaged that the cable will becomes an entirely IP access mechanism Oust like all wire-line access becomes an IP access mechanism). Then the broadcast video content will be delivered to IP enabled cable attached devices just like any other rich media will be delivered over the IP network. It is even conceivable that video encoding technologies such as MPEG2 and motion JPEG will be further improved to deliver higher resolution digital media over the cable infrastructure using NGN and CORE delivery mechanisms. The network becomes transparent and the applications and content drive the creativity of the service creation process. The PSTN like services will be delivered to devices connected via cable access just like they are delivered to other wire-line connected devices on the "New Core".

NGN Creation Strategy

The network transformation plan comprises of the following phases

Strategy

Market Trial

Service Launch

Consolidation and Optimization

Strategy

Determine where our current network fits in the evolutionary continuum from CORE to NGN or New CORE. Having identified the appropriate positioning of the network, select an architectural scenario that best serves business and technical objectives of the engagement.

Market Trial

Develop and launch a market trial that would measure and assess the viability of the introduction of the proposed service. Additionally, this trial validates the approach to transform specific parts of the infrastructure towards the "NGN" and "New Core". The market trial provides the entry-exit criteria, metrics, Key Performance Indicators etc. to assess the success of the market trial.

Service Launch

Develop, plan and manage the detailed network, systems, process and program management aspects of the launch of a "New Core" that is applicable for the network based on the strategy developed above. This ensures that the network systems planned and developed will be future-ready. The OSS and back-office systems are be able to support the processes required for service creation and management in the "New Core". The network creation processes provides the program management tools to ensure that the launch is successfully executed. These include entry and exit criteria for network creation, KPIs for quality management, program planning and management tool-kits.

Service Consolidation and Optimization

As the network operator moves into operating and maintaining the "NGN", there will be many parallel market driven journeys during which services and capabilities will be developed for the "NGN". The network creation process provides tools to assist the client into improving efficiencies of these parallel journeys. These optimization efforts will include organizational, process and technology driven changes to create efficiency based on consolidation of processes, as well as measurement tools to determine the success of such consolidation. The network architecture roadmap and business blueprint will act as the foundation to ensure that during the consolidation phase the "NGN" maintains the required architecture framework to sustain it for the long term.

Now that the details regarding the NGN have been set forth, information will now be presented concerning billing when the quality of service is degraded.

Degraded Quality of Service and Billing

A typical telecommunication network comprises multiple telecommunication switches located throughout a geographical area. When a user makes a call, the call may be routed through one or more switches before reaching its destination.

FIG. 1A illustrates an exemplary telecommunications system 102 across the United States. For purposes of illustration, a caller 104 places a call from Los Angeles, Calif. to a party 112 located in New York City, N.Y. Such a call is typically transmitted across three (3) switches: the Los Angeles, Calif. switch 106; the Chicago, Ill. switch 108; and the New York City, N.Y. switch 110. In this scenario, the originating switch is the Los Angeles, Calif. switch 106, and the terminating switch is the New York City, N.Y. switch 110.

Each of the switches, 106-110, is connected to two (2) or more Data Access Points (DAP) 116-120, for instance a primary DAP 116-120 and a backup DAP 116-120. A DAP 116-120 is a facility that receives requests for information from the switches 106-110, processes the requests, and returns the requested information back to the requesting switch 106-110. The switches 106-110 use information from the DAPs 116-120 to process calls through the network.

When a call passes through one of the switches, 106-110, that switch creates a call record. The call record contains information on the call, including but not limited to: routing, billing, call features, and trouble shooting information. After the call is terminated, each switch 106-110 that processed the call completes the associated call record. The switches 106-110 combine multiple call records into a billing block.

When a switch 106-110 fills the billing block, the switch 106-110 sends the billing block to a billing center 114. Thus, the billing center 114 receives one billing block from each switch 106-110 that handled the call, which in this case would be three billing blocks. The billing center 114 searches each billing block and retrieves the call record associated with the call, thereby retrieving one call record per switch 106-110 that handled the call. The billing center 114 then uses one or more of the retrieved call records to generate a billing entry. The billing center 114 is also connected to each DAP 116-120 to retrieve information regarding a switch 106-110 or call record. However, billing in the present invention is increased because the hybrid network also contains proxy intelligence.

FIG. 1B shows a block diagram of the Network Data Management 130 in accordance with a preferred embodiment of the present invention. Network Data Management 130 encompasses the collection of usage data and events for the purpose of network performance and traffic analysis. This data may also be an input to Billing (Rating and Discounting) processes at the Service Management Layer, depending on the service and its architecture.

The process provides sufficient and relevant information to verify compliance/non-compliance to Service Level Agreements (SLA). The process provides sufficient usage information for rating and billing.

This process ensures that the Network Performance goals are tracked, and that notification is provided when they are not met (threshold exceeded, performance degradation). This also includes thresholds and specific requirements for billing. This includes information on capacity, utilization, traffic and usage collection. In some cases, changes in traffic conditions may trigger changes to the network for the purpose of traffic control. Reduced levels of network capacity can result in requests to Network Planning for more resources.

FIG. 1B-1 is a flowchart illustrating a network data management process in accordance with a preferred embodiment. First, in step 150, data is collected relating to usage and events occurring over a hybrid network. Next, in step 152, the data is analyzed to determine a status of the hybrid network which in turn, in step 154, is utilized during management of the hybrid network. Further, in step 156, billing rates and discounts are determined based on the status of the hybrid network.

In addition to the Network Data Management 130 generating billing events, the present invention also uses a Customer Interface Management process 132, as shown in FIG. 1C, to directly interact with customers and translate customer requests and inquiries into appropriate "events" such as, the creation of an order or trouble ticket or the adjustment of a bill. This process logs customer contacts, directs inquiries to the appropriate party, and tracks the status to completion. In those cases where customers are given direct access to service management systems, this process assures consistency of image across systems, and security to prevent a customer from harming their network or those of other customers. The aim is to provide meaningful and timely customer contact experiences as frequently as the customer requires.

FIG. 1C-1 is a flowchart illustrating a Customer Interface Management Process in accordance with a preferred embodiment. First, in step 158, a service level agreement is received for a hybrid network customer. Next, in step 160, the service level agreement is stored after which, in step 162, inquiries are received from network customers reflecting occurrences related to the hybrid network. Thereafter, in step 164, events are generated based on the customer inquiries and the service level agreement.

The Network Data Management 130 and Customer Interface Management process 132 are used to give information to the Customer Quality of Service Management Process 134, as shown in FIG. 1D. The Customer Quality of Service Management Process 134 encompasses monitoring, managing and reporting of quality of service as defined in Service Descriptions, Service Level Agreements (SLA), and other service-related documents. It includes network performance, but also performance across all of service parameters, e.g., Orders Completed On Time. Outputs of this process are standard (predefined) and exception reports, including; dashboards, performance of a service against an SLA, reports of any developing capacity problems, reports of customer usage patterns, etc. In addition, this process responds to performance inquiries from the customer. For SLA violations, the process supports notifying Problem Handling and for QoS violations, notifying Service Quality Management 136. The aim is to provide effective monitoring. Monitoring and reporting must provide SP management and customers meaningful and timely performance information across the parameters of the services provided. The aim is also to manage service levels that meet specific SLA commitments and standard service commitments.

FIG. 1D-1 is a flowchart illustrating a Customer Quality of Service Management Process in accordance with a preferred embodiment. First, in step 166, a hybrid network event is received which may include customer inquiries, required reports, completion notification, quality of service terms, service level agreement terms, service problem data, quality data, network performance data, and/or network configuration data. Next, in step 168, the system determines customer reports to be generated and, in step 170, generates the customer reports accordingly based on the event received.

FIG. 1E shows a block diagram of the Service Quality Management 136 in accordance with a preferred embodiment of the present invention. The Service Quality Management Process 136 supports monitoring service or product quality on a service class basis in order to determine

Whether service levels are being met consistently

Whether there are any general problems with the service or product

Whether the sale and use of the service is tracking to forecasts.

This process also encompasses taking appropriate action to keep service levels within agreed targets for each service class and to either keep ahead of demand or alert the sales process to slow sales. The aim is to provide effective service specific monitoring, management and customers meaningful and timely performance information across the parameters of the specific service. The aim is also to manage service levels to meet SLA commitments and standard commitments for the specific service.

FIG. 1E-1 is a flowchart illustrating a Service Quality Management Process in accordance with a preferred embodiment. First, in step 172, a hybrid network event is received that may include forecasts, quality objectives, available capacity, service problem data, quality of service violations, performance trends, usage trends, problem trends, maintenance activity, maintenance progress, and/or credit violations. Next, in step 174, quality management network data is determined and, in step 176, the quality management network data is generated. Such quality management network data may include constraint data, capacity data, service class quality data, service modification recommendations, additional capacity requirements, performance requests, and/or usage requests. Finally, in step 178, a network process to which to send the generated data is identified.

FIG. 1F shows a block diagram of the Problem Handling Process 138. The Problem Handling Process receives information from the Customer Interface Management Process 132 and the Customer Quality of service Management Process 134. It is responsible for receiving service complaints from customers, resolve them to the customer's satisfaction and provide meaningful status on repair or restoration activity. This process is also responsible for any service-affecting problems, including

notifying the customer in the event of a disruption (whether reported by the customer or not),

resolving the problem to the customer's satisfaction, and

providing meaningful status on repair or restoration activity.

This proactive management also includes planned maintenance outages. The aim is to have the largest percentage of problems proactively identified and communicated to the customer, to provide meaningful status and to resolve in the shortest timeframe.

FIG. 1F-1 is a flowchart illustrating a Problem Handling Management Process in accordance with a preferred embodiment. First, in step 180, a notification of a problem within a hybrid network is received by the system. Next, in step 182, a resolution for the problem within the hybrid network is determined. The resolution may include a status report, resolution notification, problem reports, service reconfiguration, trouble notification, service level agreement violations, and/or outage notification. Finally, in step 184, the progress of the implementation of the resolution is tracked.

The Problem Handling Process 138 and the Network Data Management 130 feed information to the Rating and Discounting Process 140, as shown in FIG. 1G. This process applies the correct rating rules to usage data on a customer-by-customer basis, as required. It also applies any discounts agreed to as part of the Ordering Process, for promotional discounts and charges, and for outages. In addition, the Rating and Discounting Process 140 applies any rebates due because service level agreements were not met. The aim is to correctly rate usage and to correctly apply discounts, promotions and credits.

FIG. 1G-1 is a flowchart illustrating Rating and Discounting Process in accordance with a preferred embodiment. First, in step 185, hybrid network customer usage information is received. In step 186, network service level agreement violations are collected, and, in step 187, network quality of service violations are received by the Rating and Discounting system. Next, in step 188, rating rules are applied to the network customer usage information. Further, in step 189, negotiated discounts are determined based on the network quality of service violations and, in step 190, rebates are determined based on the network service level agreement violations. Thereafter, in step 191, billing data reflecting the usage information, the negotiated discounts, and the rebates is provided to generate a customer invoice.

Utilizing information from the Rating and Discounting Process 140, the Invoice and Collections Process 142, as shown in FIG. 1H, creates correct billing information. This process encompasses sending invoices to customers, processing their payments and performing payment collections. In addition, this process handles customer inquiries about bills, and is responsible to resolve billing problems to the customer's satisfaction. The aim is to provide a correct bill and, if there is a billing problem, resolve it quickly with appropriate status to the customer. An additional aim is to collect money due the service provider in a professional and customer supportive manner.

FIG. 1H-1 is a flowchart illustrating an Invoice and Collections Process in accordance with a preferred embodiment. First, in step 192, customer account inquiries and customer payment information is received by the system. Next, in step 193, billing data, including discounts due to quality of service violations and rebates due to service level agreement violations, is collected and processed. Thereafter, in step 194, customer account invoices are created for distribution based on the customer payment information and the billing data.

Mediation and activity tracking are provided by the event logger and event manager. The event logger and event manager feed the rating and billing information for degraded service using the personally customized rules database. Utilizing an expert system for the tailored capabilities of each customer, the event driver, collector and manager analyze notification events generated by the system. When a notification event is received the system analyzes the event and uses it to identify the customer. The notification event is also used to credit the customer if they experience a non-impacting event that breaches the customer's contract. In addition to the system itself generating the notification event, the customer is also able to notify the provider directly should such an event occur.

FIG. 2A is a flowchart illustrating media communication over the hybrid network of the present invention. When a customer initiates a use of the hybrid network, the hybrid network, in a first step 220, transfers the media over the network using IP information to route it to the appropriate destination. The media transferred over the network may be telephony data, image data, or any other data capable of packet switched transmission.

In a second step 222, events are generated based on the quality of service of the media transfer. As discussed above with reference to FIG. 1D and FIG. 1E, these events include performance notifications due to SLA violations, and customer generated events from the Customer Interface Management Process 132.

In a third step 224, the events generated in step 222 are utilized to generate a bill for the customer. In addition to normal billing for service provided via the hybrid network, the bill is modified based on events generated during the media transfer. For example, events representing SLA violations are used to credit customers. As discussed above with reference to FIGS. 1F, 1G, and 1H, the Problem Handling Process 138 is responsible for receiving service complaints and other service-affecting problems. Together with the Network Data Management 130, the Problem Handling Process feeds data to the Discounting Process 140. The Discounting Process 140 applies the correct rating rules on a customer-by-customer basis, and applies discounts for events, such as outages and other SLA violations. Finally, the Invoice and Collections Process 142, utilizes the information from the Discounting Process 140 to create customer billing information.

To better understand the invention, it is useful to describe some additional terminology relating to a telecommunication network. A telephone call comes into a switch on a transmission line referred to as the originating port, or trunk. The originating port is one of many transmission lines coming into the switch from the same location of origin. This group of ports is the originating trunk group. After processing an incoming call, the switch transmits the call to a destination location, which may be another switch, a local exchange carrier, or a private branch exchange. The call is transmitted over a transmission line referred to as the terminating port, or trunk. Similar to the originating port, the terminating port is one of a group of ports going from the switch to the same destination. This group of ports is the terminating trunk group.

Contemporary telecommunication networks provide customers with the capability of using the general public network as well as the capability of defining a custom virtual network (VNet). With a VNet, a customer defines a private dialing plan, including plan telephone numbers. A VNet customer is not limited to the default telephone numbers allocated to a public telecommunication system dedicated to a specific geographic region, but can define custom telephone numbers.

Upon processing a telephone call, a switch must generate a call record large enough to contain all of the needed information on a call. The call record, however, must not be so large that the typical call results in the majority of the record fields in the call record to be unused. In such a case, storing such call records results in large amounts of wasted storage, and transmitting such a call record causes unnecessary transmissions.

One solution for creating and processing call records is to implement a fixed length call record format, such as a 32-word call record. A word is two (2) bytes, or sixteen (16) bits. A fixed length record format, however, cannot expand when new call features are implemented. More importantly, fixed call record formats cannot handle expanded data fields as the telecommunications network becomes more complex with new features and telephone numbers.

Contemporary fixed length record formats include time point fields recording local time in three (3) second increments where local switch time represents the time of day at a switch. The timepoint fields are used by the network switches, billing center, and other network subsystems. Each subsystem, however, may require the time period for a different use and in a different format, such as in an epoch time format. Epoch time is the number of one (1) second increments since a particular date and time in history. For example, the billing center requires epoch time for its billing records whereas switch reports and error logs require local switch time.

A problem also arises when using only local switch time in that there is no accommodation for time changes due to daylight savings time. In addition, each subsystem may require a finer granularity of precision than the current three (3) second increments. By providing only local switch time at three (3) second increments, the switches have passed the burden of translating the time into a usable format to the network subsystems. The fixed record format cannot accommodate the various time period requirements because it only contains the time periods in local switch time at a low level of precision. Because of its fixed nature, the fixed record format cannot expand to include different time formats, nor to include a finer granularity of precision, such as a one (1) second increment.

Therefore, there is a need for switches of a telecommunications network to store call record information in a flexible and expandable format. There is a further need to provide time point fields with one (1) second granularity in a flexible format that easily and efficiently responds to daylight savings time and time zone changes.

There is also a need to match all of the call records associated with a specific telephone call. For example, for proper billing and cost control, it is necessary for the billing center to match the originating switch's call record to the terminating switch's call record. Also, for troubleshooting and security purposes, it may be necessary to trace a specific telephone call through the network with ease in order to isolate problem areas.

Therefore, there is a need for switches of a telecommunications network to uniquely identify each telephone call that traverses the network, thereby uniquely identifying all of the call records associated with a specific telephone call.

An Embodiment

Call Record Format

An embodiment solves the problem of providing a flexible and expandable call record format by implementing both a small and a large call record format. In particular, the embodiment implements a default 32-word call record format, plus an expanded 64-word call record format. An embodiment uses a 32-word call record format for the typical telephone call, which comprises the majority of all telephone calls, and uses a 64-word call record format when additional information is needed regarding the call. This implementation provides the flexibility needed to efficiently manage varying data requirements of a given call record. New call features can be developed and easily incorporated into the variable call record format of the present invention.

This embodiment also records timepoints in the epoch time format. The embodiment records the origination time of a call in epoch time format, and the remaining timepoints are offsets, or the number of seconds, from that origination time. This embodiment solves the problems associated with converting to and from daylight savings time because daylight savings time is a local time offset and does not affect the epoch time. Furthermore, the timepoints in epoch time format require less space in the call record than they do in local switch time format.

The epoch time format may represent coordinated universal time (UTC), as determined at Greenwich, England, which has a time zone of zero (0) local switch time, or any other time. Epoch time is only a format and does not dictate that UTC must be used. The billing time and the local switch time may be in UTC or local time, and the local switch time may not necessarily be the same time that is used for billing. Therefore, the switch must keep billing time and local switch time separate in order to prevent the problems that occur during daylight savings time changes.

Network Call Identifier

This embodiment solves the problem of uniquely identifying each telephone call and all of the call records associated with a specific telephone call by providing a unique identifier to each call record. It generates a network call identifier (NCID) that is assigned to each call record at the point of call origination, that is, the originating switch generates an NCID for each telephone call. The NCID accompanies the associated telephone call through the telecommunications network to the termination point at the terminating switch. Therefore, at any point of a telephone call in the network, the associated NCID identifies the point and time of origin of the telephone call. Each switch through which the telephone call passes records the NCID in the call record associated with the call. The NCID is small enough to fit in a 32-word call record, thereby reducing the data throughput and storage. The NCID provides the billing center and other network subsystems with the ability to match originating and terminating call records for a specific telephone call.

This embodiment also provides the switch capability of discarding a received NCID and generating a new NCID. A switch discards a received NCID if the NCID format is invalid or unreliable, thereby ensuring a valid unique identifier to be associated with each call going through the network. For instance, an NCID may be unreliable if generated by third party switches in the telecommunications network.

This embodiment relates to switches of a telecommunication network that generate call records using a flexible and expandable record format. The call record formats include a small (preferably 32-word) and a large (preferably 64-word) expanded format. It would be readily apparent to one skilled in the relevant art to implement a small and large record format of different sizes.

The embodiment also relates to switches of a telecommunication network that generate a unique NCID for each telephone call traversing the network. The NCID provides a mechanism for matching all of the call records associated with a specific telephone call. It would be readily apparent to one skilled in the relevant art to implement a call record identifier of a different format.

The chosen embodiment is computer software executing within a computer system. FIG. 2B shows an exemplary computer system. The computer system 202 includes one or more processors, such as a processor 204. The processor 204 is connected to a communication bus 206.

The computer system 202 also includes a main memory 208, preferably random access memory (RAM), and a secondary memory 210. The secondary memory 210 includes, for example, a hard disk drive 212 and/or a removable storage drive 214, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive 214 reads from and/or writes to a removable storage unit 216 in a well known manner.

Removable storage unit 216, also called a program storage device or a computer program product, represents a floppy disk, magnetic tape, compact disk, etc. The removable storage unit 216 includes a computer usable storage medium having therein stored computer software and/or data.

Computer programs (also called computer control logic) are stored in main memory 208 and/or the secondary memory 210. Such computer programs, when executed, enable the computer system 202 to perform the functions of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 204 to perform the functions of the present invention. Accordingly, such computer programs represent controllers of the computer system 202.

Another embodiment is directed to a computer program product comprising a computer readable medium having control logic (computer software) stored therein. The control logic, when executed by the processor 204, causes the processor 204 to perform the functions as described herein.

Another embodiment is implemented primarily in hardware using, for example, a hardware state machine. Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant arts.

Call Record Format

This embodiment provides the switches of a telecommunication network with nine (9) different record formats. These records include: Call Detail Record (CDR), Expanded Call Detail Record (ECDR), Private Network Record (PNR), Expanded Private Network Record (EPNR), Operator Service Record (OSR), Expanded Operator Service Record (EOSR), Private Operator Service Record (POSR), Expanded Private Operator Service Record (EPOSR), and Switch Event Record (SER). Each record is 32 words in length, and the expanded version of each record is 64 words in length.

Example embodiments of the nine (9) call record formats discussed herein are further described in FIGS. 1-5. The embodiments of the call records of the present invention comprise both 32-word and 64-word call record formats. It would be apparent to one skilled in the relevant art to develop alternative embodiments for call records comprising a different number of words and different field definitions. Table 301 of the Appendix contains an example embodiment of the CDR and PNR call record formats. FIG. 3 shows a graphical representation of the CDR and PNR call record formats. Table 302 of the Appendix contains an example embodiment of the ECDR and EPNR call record formats. FIGS. 4A and 4B show a graphical representation of the ECDR and EPNR call record formats. Table 303 of the Appendix contains an example embodiment of the OSR and POSR call record formats. FIG. 5 shows a graphical representation of the OSR and POSR call record format. Table 304 of the Appendix contains an example embodiment of the EOSR and EPOSR call record formats. FIGS. 6(A) and 6(B) show a graphical representation of the EOSR and EPOSR call record formats. Table 305 of the Appendix contains an embodiment of the SER record format. FIG. 7 shows a graphical representation of the SER record format.

The CDR and PNR, and thereby the ECDR and EPNR, are standard call record formats and contain information regarding a typical telephone call as it passes through a switch. The CDR is used for a non-VNET customer, whereas the PNR is used for a VNET customer and is generated at switches that originate VNET calls. The fields of these two records are identical except for some field-specific information described below.

The OSR and POSR, and thereby the EOSR and EPOSR, contain information regarding a telephone call requiring operator assistance and are generated at switches or systems actually equipped with operator positions. A switch completes an OSR for a non-VNET customer and completes a POSR for a private VNET customer. These records are only generated at switches or systems that have the capability of performing operator services or network audio response system (NARS) functions. The formats of the two (2) records are identical except for some field-specific information described below.

A SER is reserved for special events such as the passage of each hour mark, time changes, system recoveries, and at the end of a billing block. The SER record format is also described in more detail below.

FIGS. 8(A) and 8(B) collectively illustrate the logic that a switch uses to determine when to use an expanded version of a record format. A call 202 comes into a switch 106-110 (called the current switch for reference purposes; the current switch is the switch that is currently processing the call), at which time that switch 106-110 determines what call record and what call record format (small/default or large/expanded) to use for the call's 802 call record. In this regard, the switch 106-110 makes nine (9) checks for each call 802 that it receives. The switch 106-110 uses an expanded record for a call 802 that passes any check as well as for a call 802 that passes any combination of checks.

The first check 804 determines if the call is involved in a direct termination overflow (DTO) at the current switch 106-110. For example, a DTO occurs when a customer makes a telephone call 802 to an 800 number and the original destination of the 800 number is busy. If the original destination is busy, the switch overflows the telephone call 802 to a new destination. In this case, the switch must record the originally attempted destination, the final destination of the telephone call 802, and the number of times of overflow. Therefore, if the call 802 is involved in a DTO, the switch 106-110 must complete an expanded record (ECDR, EPNR, EOSR, EPOSR) 816.

The second check 806 made on a call 802 by a switch 106-110 determines if the calling location of the call 802 is greater than ten (10) digits. The calling location is the telephone number of the location from where the call 802 originated. Such an example is an international call which comprises at least eleven (11) digits. If the calling location is greater than ten (10) digits, the switch records the telephone number of the calling location in an expanded record (ECDR, EPNR, EOSR, EPOSR) 816.

A switch 106-110 makes a third check 808 on a call 802 to determine if the destination address is greater than seventeen (17) digits. The destination address is the number of the called location and may be a telephone number or trunk group. If the destination is greater than seventeen (17) digits, the switch records the destination in an expanded record (ECDR, EPNR, EOSR, EPOSR) 816.

A switch 106-110 makes a fourth check 810 on a call 802 to determine if the pre-translated digits field is used with an operated assisted service call. The pre-translated digits are the numbers of the call 802 as dialed by a caller if the call 202 must be translated to another number within the network. Therefore, when a caller uses an operator service, the switch 106-110 records the dialed numbers in expanded record (EOSR, EPOSR) 816.

In a fifth check 812 on a call 802, a switch 106-110 determines if the pre-translated digits of a call 802 as dialed by a caller without operator assistance has more than ten (10) digits. If there are more than ten (10) pre-translated digits, the switch 106-110 records the dialed numbers in expanded record (ECDR, EPNR) 816.

In a sixth check 814 on a call 802, a switch 106-110 determines if more than twenty-two (22) digits, including supplemental data, are recorded in the Authorization Code field of the call record. The Authorization Code field indicates a party who gets billed for the call, such as the calling location or a credit card call. If the data entry requires more than twenty-two (22) digits, the switch 106-110 records the billing information in an expanded record (ECDR, EPNR, EOSR, EPOSR) 816.

In a seventh check 820 on a call 802, a switch 106-110 determines if the call 802 is a wideband call. A wideband call is one that requires multiple transmission lines, or channels. For example, a typical video call requires six (6) transmission channels one (1) for voice and five (5) for the video transmission. The more transmission channels used during a wideband call results in a better quality of reception. Contemporary telecommunication systems currently provide up to twenty-four (24) channels. Therefore, to indicate which, and how many, of the twenty-four channels is used during a wideband call, the switch records the channel information in an expanded record (ECDR, EPNR) 828.

In an eighth check 822 on a call 802, a switch 106-110 determines if the time and charges feature was used by an operator. The time and charges feature is typically used in a hotel scenario when a hotel guest makes a telephone call using the operator's assistance and charges the call 802 to her room. After the call 802 has completed, the operator informs the hotel guest of the charge, or cost, of the call 802. If the time and charges feature was used with a call 802, the switch 106-110 records the hotel guest's name and room number in an expanded record (EOSR, EPOSR) 832.

The ninth, and final, check 824 made on a call 802 by a switch 106-110 determines if the call 802 is an enhanced voice service/network audio response system (EVS/NARS) call. An EVS/NARS is an audio menu system in which a customer makes selections in response to an automated menu via her telephone key pad. Such a system includes a NARS switch on which the audio menu system resides. Therefore, during an EVS/NARS call 802, the NARS switch 106-110 records the customer's menu selections in an expanded record (EOSR, EPOSR) 832.

If none of the checks 804-824 return a positive result, then the switch 106-110 uses the default record format (OSR, POSR) 830.

Once the checks have been made on a call, a switch generates and completes the appropriate call record. Call record data is recorded in binary and Telephone Binary Coded Decimal (TBCD) format. TBCD format is illustrated below:

0000=TBCD-Null

0001=digit 1

0010=digit 2

0011=digit 3

0100=digit 4

0101=digit 5

0110=digit 6

0111=digit 7

1000=digit 8

1001=digit 9

1010=digit 0

1011=special digit 1 (DTMF digit A)

1100=special digit 2 (DTMF digit B)

1101=special digit 3 (DTMF digit C)

1110=special digit 4 (DTMF digit D)

1111=special digit 5 (Not Used)

All TBCD digit fields must be filled with TBCD-Null, or zero, prior to data being recorded. Where applicable, dialed digit formats conform to these conventions

N=digits 2-9

X=digits 0-9

Y=digits 2-8

Thus, if the specification for a call record field contains a N, the valid field values are the digits 2-9.

Each call record, except SER, contains call specific timepoint fields. The timepoint fields are recorded in epoch time format. Epoch time is the number of one second increments from a particular date/time in history. The embodiment of the present invention uses a date/time of midnight (00:00 am UTC) on Jan. 1, 1976, but this serves as an example and is not a limitation. It would be readily apparent to one skilled in the relevant art to implement an epoch time based on another date/time. In the records, Timepoint 1 represents the epoch time that is the origination time of the call 802. The other timepoint stored in the records are the number of seconds after Timepoint 1, that is, they are offsets from Timepoint 1 that a particular timepoint occurred. All of the timepoint fields must be filled in with "0's" prior to any data being recorded. Therefore, if a timepoint occurs, its count is one (1) or greater. Additionally, timepoint counters, not including Timepoint 1, do not rollover their counts, but stay at the maximum count if the time exceeds the limits.

The switch clock reflects local switch time and is used for all times except billing. Billing information is recorded in epoch time, which in this embodiment is UTC. The Time offset is a number reflecting the switch time relative to the UTC, that is, the offset due to time zones and, if appropriate, daylight savings time changes. There are three factors to consider when evaluating time change relative to UTC. First, there are time zones on both sides of UTC, and therefore there may be both negative and positive offsets. Second, the time zone offsets count down from zero (in Greenwich, England) in an Eastward direction until the International Dateline is reached. At the Dateline, the date changes to the next day, such that the offset becomes positive and starts counting down until the zero offset is reached again at Greenwich. Third, there are many areas of the world that have time zones that are not in exact one-hour increments. For example, Australia has one time zone that has a thirty (30) minute difference from the two time zones on either side of it, and Northern India has a time zone that is fifteen (15) minutes after the one next to it. Therefore, the Time Offset of the call records must account for variations in both negative and positive offsets in fifteen (15) minute increments. The embodiment of the present invention satisfies this requirement by providing a Time Offset representing either positive or negative one minute increments.

There are two formulas used to convert local switch time to epoch time and back.

i) Epoch Time+(Sign Bit*Time Offset)=Local Switch Time

ii) Local Switch Time-(Sign Bit*Time Offset)=Epoch Time

The switch records the Time Offset in the SER using a value where one (1) equals one (1) minute, and computes the Time Offset in seconds and adds this value to each local Timepoint 1 before the call record is recorded. For example, Central Standard Time is six (6) hours before UTC. In this case, the Sign Bit indicates "1" for negative offset and the Time Offset value recorded in the SER would be 360 (6 hours*60 minutes/hour=360 minutes). See FIG. 5 for more details on the SER record format. When recording Timepoint 1 in the call record, the switch multiplies the Time Offset by 60, because there is 60 seconds in each 1 minute increment, and determines whether the offset is positive or negative by checking the Sign Bit. This example results in a value of -21,600 (-1*360 minutes*60 seconds/minute=-21,600 seconds). Using equation (ii) from above, if the local switch time were midnight, the corresponding epoch time might be, for example, 1,200,000,000. Subtracting the Time Offset of -21,600 results in a corrected epoch time of 1,200,021,600 seconds, which is the epoch time for 6 hours after midnight on the next day in epoch time. This embodiment works equally as well in switches that are positioned on the East side of Greenwich where the Time Offset has a positive value.

Two commands are used when changing time. First, FIG. 9 illustrates the control flow of the Change Time command 900, which changes the Local Switch Time and the Time Offset. In FIG. 9, after a switch operator enters the Change Time command, the switch enters step 902 and prompts the switch operator for the Local Switch Time and Time Offset from UTC. In step 902 the switch operator enters a new Local Switch Time and Time Offset. Continuing to step 904, the new time and Time Offset are displayed back to the switch operator. Continuing to step 906, the switch operator must verify the entered time and Time Offset before the actual time and offset are changed on the switch. If in step 906 the switch operator verifies the changes, the switch proceeds to step 908 and generates a SER with an Event Qualifier equal to two which identifies that the change was made to the Local Switch Time and Time Offset of the switch. The billing center uses the SER for its bill processing. The switch proceeds to step 910 and exits the command. Referring back to step 906, if the switch operator does not verify the changes, the switch proceeds to step 910 and exits the command without updating the Local Switch Time and Time Offset. For more information on SER, see FIG. 5.

FIG. 10 illustrates the control flow for the Change Daylight Savings Time command 1000 which is the second command for changing time. In FIG. 10, after a switch operator enters the Change Daylight Savings Time command, the switch enters step 1002 and prompts the switch operator to select either a Forward or Backward time change. Continuing to step 1004, the switch operator makes a selection. In step 1004, if the switch operator selects the Forward option, the switch enters step 1006. In step 1006, the switch sets the Local Switch Time forward one hour and adds one hour (count of 60) to the Time Offset. The switch then proceeds to step 1010.

Referring back to step 1004, if the switch operator selects the Backward option, the switch sets the Local Switch Time back one hour and subtract one hour (count of 60) from the Time Offset. The switch then proceeds to step 1010.

In step 1010, the switch operator must verify the forward or backward option and the new Local Switch Time and Time Offset before the actual time change takes place. If in step 1010, the switch operator verifies the new time and Time Offset, the switch proceeds to step 1012 and generates a SER with an Event Qualifier equal to nine which changes the Local Switch Time and Time Offset of the switch. The switch proceeds to step 1014 and exits the command. Referring back to step 1010, if the switch operator does not verify the changes, the switch proceeds to step 1014 and exits the command without updating the Local Switch Time and Time Offset.

After the successful completion of a Change Daylight Savings Time Command, the billing records are affected by the new Time Offset. This embodiment allows the epoch time, used as the billing time, to increment normally through the daylight savings time change procedure, and not to be affected by the change of Local Switch Time and Time Offset.

Network Call Identifier

An embodiment provides a unique NCID that is assigned to each telephone call that traverses through the telecommunications network. Thus, the NCID is a discrete identifier among all network calls. The NCID is transported and recorded at each switch that is involved with the telephone call.

The originating switch of a telephone call generates the NCID. The chosen embodiment of the NCID of the present invention is an eighty-two (82) bit identifier that is comprised of the following subfields:

i) Originating Switch ID (14 bits): This field represents the NCS Switch ID as defined in the Office Engineering table at each switch. The SER call record, however, contains an alpha numeric representation of the Switch ID. Thus, a switch uses the alphanumeric Switch ID as an index into a database for retrieving the corresponding NCS Switch ID.

ii) Originating Trunk Group (14 bits): This field represents the originating trunk group as defined in the 32/64-word call record format described above.

iii) Originating Port Number (19 bits): This field represents the originating port number as defined in the 32/64-word call record format described above.

iv) Timepoint 1 (32 bits): This field represents the Timepoint 1 value as defined in the 32/64-word call record format described above.

v) Sequence Number (3 bits): This field represents the number of calls which have occurred on the same port number with the same Timepoint 1 (second) value. The first telephone call will have a sequence number set to `0.` This value increases incrementally for each successive call which originates on the same port number with the same Timepoint 1 value.

It would be readily apparent to one skilled in the relevant art to create an NCID of a different format. Each switch records the NCID in either the 32 or 64-word call record format. Regarding the 32-word call record format, intermediate and terminating switches will record the NCID in the AuthCode field of the 32-word call record if the AuthCode filed is not used to record other information. In this case, the Originating Switch ID is the NCS Switch ID, not the alphanumeric Switch ID as recorded in the SER call record. If the AuthCode is used for other information, the intermediate and terminating switches record the NCID in the 64-word call record format. In contrast, originating switches do not use the AuthCode field when storing an NCID in a 32-word call record. Originating switches record the subfields of the NCID in the corresponding separate fields of the 32-word call record. That is, the Originating Switch ID is stored as an alphanumeric Switch ID in the Switch ID field of the SER call record; the Originating Trunk Group is stored in the Originating Trunk Group field of the 32-word call record; the Originating Port Number is stored in the Originating Port field of the 32-word call record; the Timepoint 1 is stored in the Timepoint 1 field of the 32-word call record; the Sequence Number is stored in the NCID Sequence Number field of the 32-word call record. The 32-word call record also includes an NCID Location (NCIDLOC) field to identify when the NCID is recorded in the AuthCode field of the call record. If the NCID Location field contains a `1,` then the AuthCode field contains the NCID. If the NCID Location field contains a `0,` then the NCID is stored in its separate sub-fields in the call record. Only intermediate and terminating switches set the NCID Location field to a `1` because originating switches store the NCID in the separate fields of the 32-word call record.

Regarding the 64-word call record format, the expanded call record includes a separate field, call the NCID field, to store the 82 bits of the NCID. This call record is handled the same regardless of whether an originating, intermediate, or terminating switch stores the NCID. In the 64-word call record format, the Originating Switch ID is the NCS Switch ID, not the alphanumeric Switch ID as recorded in the SER call record.

FIG. 11 illustrates the control flow of the Network Call Identifier switch call processing. A call 202 comes into a switch 106-110 (called the current switch for reference purposes; the current switch is the switch that is currently processing the call) at step 1104. In step 1104, the current switch receives the call 202 and proceeds to step 1106. In step 1106, the current switch accesses a local database and gets the trunk group parameters associated with the originating trunk group of the call 202. After getting the parameters, the current switch proceeds to step 1108. In step 1108, the current switch determines if it received an NCID with the call 202. If the current switch did not receive an NCID with the call 202, the switch continues to step 1112.

In step 1112, the switch analyzes the originating trunk group parameters to determine the originating trunk group type. If the originating trunk group type is an InterMachine Trunk (IMT) or a release link trunk (RLT), then the switch proceeds to step 1116. An IMT is a trunk connecting two normal telecommunication switches, whereas a RLT is a trunk connecting an intelligent services network (ISN) platform to a normal telecommunication switch. When the current switch reaches step 1116, the current switch knows that it is not an originating switch and that it has not received an NCID. In step 1116, the current switch analyzes the originating trunk group parameters to determine whether it is authorized to create an NCID for the call 202. In step 1116, if the current switch is not authorized to create an NCID for the call 202, the current switch proceeds to step 1118. When in step 1118, the current switch knows that it is not an originating switch, it did not receive an NCID for the call 202, but is not authorized to generate an NCID. Therefore, in step 1118, the current switch writes the call record associated with the call 202 to the local switch database and proceeds to step 1120. In step 1120, the current switch transports the call 202 out through the network with its associated NCID. Step 1120 is described below in more detail.

Referring again to step 1116, if the current switch is authorized to create an NCID for the call 202, the current switch proceeds to step 1114. In step 1114, the current switch generates a new NCID for the call 202 before continuing to step 1136. In step 1136, the current switch writes the call record, including the NCID, associated with the call 202 to the local switch database and proceeds to step 1120. In step 1120, the current switch transports the call 202 out through the network with its associated NCID. Step 1120 is described below in more detail.

Referring again to step 1112, if the current switch determines that the originating =trunk group type is not an IMT or RLT, the current switch proceeds to step 1114. When reaching step 1114, the current switch knows that it is an originating switch and, therefore, must generate a NCID for the call 202. Step 1114 is described below in more detail. After generating a NCID in step 1114, the current switch proceeds to step 1136 to write the call record, including the NCID, associated with the call 202 to the local database. After writing the call record, the current switch proceeds to step 1120 to transport the call out through the network with its associated NCID. Step 1120 is also described below in more detail.

Referring again to step 1108, if the current switch determines that it received an NCID with the call 202, the current switch proceeds to step 1110. In step 1110, the current switch processes the received NCID. In step 1110, there are two possible results. First, the current switch may decide not to keep the received NCID thereby proceeding from step 1110 to step 1114 to generate a new NCID. Step 1110 is described below in more detail. In step 1114, the current switch may generate a new NCID for the call 202 before continuing to step 1136. Step 1114 is also described below in more detail. In step 1136, the current switch writes the call record associated with the call 202 to the local database. The current switch then proceeds to step 1120 and transports the call 202 out through the network with its associated NCID. Step 1120 is also described below in more detail.

Referring again to step 1110, the current switch may decide to keep the received NCID thereby proceeding from step 1110 to step 1115. In step 1115, the current switch adds the received NCID to the call record associated with the call 202. Steps 1110 and 1115 are described below in more detail. After step 1115, the current switch continues to step 1136 where it writes the call record associated with the call 202 to the local database. The current switch then proceeds to step 1120 and transports the call 202 out through the network with its associated NCID. Step 1120 is also described below in more detail.

FIG. 12 illustrates the control logic for step 1110 which processes a received NCID. The current switch enters step 1202 of step 1110 when it determines that an NCID was received with the call 202. In step 1202, the current switch analyzes the originating trunk group parameters to determine the originating trunk group type. If the originating trunk group type is an IMT or RLT, then the current switch proceeds to step 1212. When in step 1212, the current switch knows that it is not an originating switch and that it received an NCID for the call 202. Therefore, in step 1212, the current switch keeps the received NCID and exits step 1110, thereby continuing to step 1115 in FIG. 11, after which the current switch will store the received NCID in the call record and transport the call.

Referring again to step 1202, if the originating trunk group type is not an IMT or RLT, the current switch proceeds to step 1204. In step 1204, the current switch determines if the originating trunk group type is an Integrated Services User Parts Direct Access Line (ISUP DAL) or an Integrated Services Digital Network Primary Rate Interface (ISDN