WO2000003550A1

WO2000003550A1 - Hypertext transport protocol interface in an intelligent network node

Info

Publication number: WO2000003550A1
Application number: PCT/US1999/015341
Authority: WO
Inventors: Adam Roach
Original assignee: Ericsson Inc.
Priority date: 1998-07-08
Filing date: 1999-07-07
Publication date: 2000-01-20
Also published as: CA2336442A1; AU4865399A; EP1095525A1; CN1308817A

Abstract

A telecommunications system and method is disclosed for providing a direct hypertext transfer protocol (http) interface (330) into an IN node (320) containing subscriber and/or network information. The http interface (325) provides a method of remotely administering an IN node (320) that combines the platform independence and manageability of a text interface with the shallow learning curve and useability of a graphical interface. With this direct http interface (325), any computer, workstation, or other web-capable machine (300) connected to the same data network (210) as the IN node (320) can start a web browser (310), e.g., Netscape, Internet Explorer, etc., type in a Uniform Resource Locator (URL) (308), which is an identification of the IN node (320) the user wishes to access, and access the IN node (320) in order to enter administrative functions from the web browser (310).

Description

HYPERTEXT TRANSPORT PROTOCOL INTERFACE IN AN INTELLIGENT NETWORK NODE

BACKGROUND OF THE PRESENT INVENTION Field of the Invention

The present invention relates generally to telecommunications systems and methods for accessing and manipulating subscriber or network information stored in an Intelligent Network (IN) node, and specifically to providing a direct hypertext transfer protocol (http) interface to the IN node. Background and Objects of the Present Invention

In modern telecommunications networks, signaling constitutes the distinct control infrastructure that enables provision of all other services. It can be defined as the system that enables stored program control exchanges, network databases, and other "intelligent" nodes of the network to exchange: (a) messages related to call setup, supervision, and tear-down; (b) information needed for distributed applications processing (inter-process query/response); and (c) network management information.

In addition, the Intelligent Network (IN) and the new Advanced Intelligent

Network (ATN) have made possible the transfer of all types of information through the telephone network without special circuits or long installation cycles. In the IN, everything is controlled or configured by workstations with user-friendly software.

Telephone service representatives can, therefore, create new services and tailor a subscriber's service from a terminal while talking with the customer. These changes are immediately and inexpensively implemented in the switches, rather than by the more traditional method: expensive programming changes made by certified technicians.

The IN consists of a series of intelligent nodes, each capable of processing at various levels, and each capable of communicating with one another over data links. The basic infrastructure needed is composed of various signaling points, which both perform message discrimination (read the address and determine if the message is for that node), and route messages to other signaling points. The basic three types of signaling points are: (1) Service Switching Points (SSPs); (2) Signal Transfer Points (STPs); and (3) Service Control Points (SCPs), each of which are described in more detail hereinafter.

With reference now to FIGURE 1 of the drawings, the many Service Switching Points (SSPs) 100 serve as the local exchanges in a telephone network 90, a portion of which is shown in FIGURE 1. The SSPs 100 also provide an Integrated Services Digital Network (ISDN) interface for the Signal Transfer Points (STPs) 110, as is understood in the art. ISDN signaling uses a separate channel and is compatible with the IN. The signaling information is handed off to the IN network and transferred to the end office (another SSP) using an ISDN User Part (ISUP) protocol, which is responsible for all call setup and tear down.

The STP 110 serves as a router, and switches messages received from a particular SSP 100 through the network 90 to their appropriate destinations (another SSP 100). As is also understood in the art, the STP 110 receives messages in packet form from the SSPs 100. These packets are either related to call connections or database queries. If the packet is a request to connect a call, the message must be forwarded to a destination end office (another SSP 100), where the call will be terminated.

If, however, the message is a database query seeking additional information, the destination will be a database. Database access is provided through the Service

Control Point (SCP) 120, which does not store the information, but acts as an interface to a computer that houses the requested information.

Currently, information pertaining to a telecommunications network and/or subscribers can be stored in an IN node, instead of traditional nodes, such as a Home Location Register (HLR) or SSP, as is known in the art. Access to the information contained in these IN nodes traditionally has been provided through cryptic text commands entered by the technician on the IN node itself. Unfortunately, the text commands used for administration are difficult to learn, and require a great deal of user documentation. Alternatively, in some situations, platform-specific, single- purpose graphical user interfaces (GUIs) have been used for administration. While the

GUIs are generally much easier to use, they require a great deal of time to program and maintain, they must be ported and recompiled for every platform they are to run on, and the user has to use a different program for each type of administration they wish to perform. In fact, due to the overhead in writing and deploying these GUIs, most administrative functions have only text interfaces. With reference now to FIGURE 2 of the drawings, an alternative way of remotely accessing the information contained in these IN nodes 240, which is not widely used today, utilizes a web server 220. A user 200, t ., a computer, can request access to a specific web page or file 245 associated with the IN node 240 by entering an address, e^, http://www.URL.com/file, from a web browser 205, e.g.. Netscape or Internet Explorer, within the computer 200, which can then determine which web server 220 to send the hypertext transfer protocol (http) request to based upon the entered Uniform Resource Locator (URL), which is an identification of the IN node 240 the user 200 wishes to access. The web browser 205 can then send the request to that web server 220 through a data network 210, e^, the computer's 200 modem can dial a number for an Internet Service Provider (ISP) (not shown), and an SSP 100 or end office serving the user 200 can route the call to the ISP, which can then route the request through various network devices (not shown), such as hubs, routers and bridges, as is understood in the art. Alternatively, if the user 200 is connected to a dedicated network (private intranet), which is the more likely scenario, the web browser 205 can send the request directly to the web server 220 through the various network devices.

Thereafter, the web server 220 can then establish a connection with the IN node 240 associated with the address using an intermediating Common Gateway Interface (CGI script) 230. The IN node 240 can then retrieve the requested file (web page) 245 and send the file 245 back to the user 200 through the web server 220 and the data network 210 for display on a computer screen 202. The user 200 can then manipulate the data within the web page 245, which is displayed on the screen 202, from the web browser 205 on the remote computer 200. However, general-purpose web servers 220 are complex and difficult to administer, and typically require a full- time employee to ensure proper operation. In addition, utilizing web servers 220 to access information from IN nodes 240 requires an increase in interprocess communications, which provides for inefficient use of network resources. Furthermore, the code required to create and maintain the interface between the web server 220 and the IN node, e.g.. the CGI script, is cumbersome to administer and update. It is, therefore, an object of the present invention to provide a direct hypertext transfer protocol (http) interface to an IN node in order to allow remote administration ofthe lN node.

SUMMARY OF THE INVENTION The present invention is directed to telecommunications systems and methods for providing a direct hypertext transfer protocol (http) interface into an IN node containing subscriber and/or network information. The http interface provides a method of remotely administering an IN node that combines the platform independence and manageability of a text interface with the shallow learning curve and useability of a graphical interface. With this direct http interface, any computer, workstation, or other web-capable machine connected to the same data network as the IN node can start a web browser, e^, Netscape, Internet Explorer, etc., type in a Uniform Resource Locator (URL), which is an identification of the IN node the user wishes to access, and access the IN node in order to enter administrative functions from the web browser. Advantageously, since the http specification is done specifically for the IN node, no traditional web server is required. In addition, a great deal of processing overhead is eliminated by cutting down on the interprocess communication that would be necessary for a traditional web server. Finally, the code required to create and maintain the interface is significantly reduced, as the need for an intermediating CGI script is not necessary.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed inventions will be described with reference to the accompanying drawings, which show sample embodiments of the invention and which are incorporated in the specification hereof by reference, wherein: FIGURE 1 is a block diagram illustrating some of the basic components used in an Intelligent Network (IN) or an Advanced Intelligent Network for signal switching;

FIGURE 2 is a block diagram illustrating accessing an IN node using a web server and intermediating Common Gateway Interface (CGI script);

FIGURE 3 is a block diagram illustrating a direct remote connection with an IN node within a telecommunications network using a hypertext transfer protocol (http) interface in accordance with preferred embodiments of the present invention; and FIGURE 4 shows steps in a sample process of remotely accessing an IN node within the telecommunications network using the http interface and a web browser.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS The numerous innovative teachings of the present application will be described with particular reference to the presently preferred exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily delimit any of the various claimed inventions. Moreover, some statements may apply to some inventive features but not to others.

With reference now to FIGURE 3 of the drawings, a hypertext transfer protocol (http) interface 330 can be implemented directly into an Intelligent Network (IN) node 320 to provide a method of remotely administering the IN node 320 that combines the platform independence and manageability of a text interface with the shallow learning curve and useability of a graphical interface. The IN node 320 can contain, for example, network and/or subscriber information. By providing a direct http interface 330, any personal computer (PC) 300, workstation, or other web-capable machine connected to the same data network as the IN node 320 can start a "web browser" 310, £ ^, Netscape or Internet Explorer, within the computer 300, and type in a Uniform

Resource Locator (URL) 308, which is an identification of the information the user wishes to access, in order to enter administrative functions for the IN node 320 directly from the web browser 310.

In order to accommodate this functionality, the IN node 320 must first open a listener port 325, e.g., a Transmission Control Protocol/Internet Protocol (TCP/IP) listener port 325, to which the web browser 310 can connect. The TCP/IP was developed as a standard protocol to allow different types of computers to exchange electronic mail and other files over a network. The TCP/IP specifies the addressing of nodes on the Internet and provides a method of sending packets of data from one node to another. The TCP is an application implemented on top of the IP to provide reliable delivery of the data packets end-to-end. It should be understood that other protocols can be used instead of TCP/IP, such as the User Datagram Protocol (UDP), which is faster than the TCP, but less reliable.

Once the "web browser" 310 makes a connection, the "web browser" 310 sends an http request 305 to the IN node 320. Thereafter, the IN node 320 parses the request 305, performs any relevant actions based upon the user's request 305, and sends back the requested data or a confirmation that the requested action has been performed.

With reference now to FIGURE 4 of the drawings, which will be described in connection with FIGURE 3 of the drawings, in order to access the IN node 320 (step 450), the user must first start-up the "web browser" 310 on the user's computer 300 (step 400) and type in the URL 308 (step 410) formed by the IN node 320 name and the predetermined TCP port 325 number the IN node 320 listens to. If, for example, the IN node 320 is called "fonzie" and the port 325 number is 9022, the URL 308 can be "http://fonzie:9022/." The user's "web browser" 310 then attempts to contact fonzie 320 on TCP port 325 number 9022 (step 420). When the "web browser" 310 connects to port 325 number 9022 on fonzie 320

(step 420), the web browser 310 can then send an http request 305 (step 430), as is understood in the art. The http interface 330 within the IN node 320 then decodes the http request 305 (step 440) by determining the type of request 305, such as a "GET" request 305, which instructs the IN node 320 to retrieve information, and the exact type of data being requested. The type of data being requested can be specified by any information after the final slash in the URL 308, e^, if the user wishes to access system status information, the URL 308 can be "http://fonzie:9022/status". It should be noted that access to certain information can be password protected, and this password can be included in the URL 308 or prompted by the http interface 330 when the URL 308 is received. In preferred embodiments of the present invention, the actual URL 308, including the type of information required, can be kept transparent to the user by displaying a menu on a display or screen 302 of the computer 300 if no indication of the desired information is included.

Furthermore, the request 305 can include attributes which modify the request 305. For example, if the user desires information concerning calls placed to the phone number "555-1234" for the past five days, the format of the URL 308 can be:

"http://fonzie:9022/statistics?number =5551234&days=5". This format is compliant with the http specification for sending back information from user forms.

Based upon the type of data requested and additional attributes (if any), the http interface 330 within the IN node 320 can then generate a markup language page 340, such as a Hypertext Markup Language (HTML) page 340 (step 450), which is sent to the computer 300 from the http interface 330 via the web browser 310 (step 460). The HTML page 340 contains the information that the user requested and presents this information to the user via the web browser 310 on the computer screen 302. In addition, the HTML page 340 can contain further links to request different information from the IN node 320 and links which point to other information contained on other

IN nodes and traditional web servers (not shown).

It should be understood that other markup languages can be used, such as the Extensible Markup Language (XML), instead of the HTML discussed herein. In addition, it should also be understood that the web browser 310 can be resident within the IN node 320 itself. Thus, instead of remotely accessing the IN node 320, the administration of the IN node 320 can be performed at the IN node 320 through the use of the web browser 310.

By implementing the http specification 330 on the IN node 320 itself, no traditional "web server" is required. Thus, a great deal of processing overhead is eliminated by cutting down on the interprocess communication which are necessary with traditional web servers. In addition, the code required to create and maintain the interface is significantly reduced, as the need for an intermediating "Common Gateway Interface (CGI) script" is not necessary.

As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications. Accordingly, the scope of patented subject matter should not be limited to any of the specific exemplary teachings discussed, but is instead defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A telecommunications system for accessing an Intelligent Network (IN) node within said telecommunications system, said telecommunications system comprising: a web-capable machine having a web browser associated therewith, said web- capable machine being connected to said IN node using said web browser; and a hypertext transport protocol (http) interface associated with said IN node, said web browser accessing said IN node via said http interface.

2. The telecommunications system of Claim 1, wherein said IN node opens a port to enable said web browser to access said IN node.

3. The telecommunications system of Claim 2, wherein said port is a Transmission Control Protocol/Internet Protocol port.

4. The telecommunications system of Claim 2, wherein said web browser uses a Uniform Resource Locator (URL) to connect with said http interface.

5. The telecommunications system of Claim 4, wherein said URL contains a name associated with said IN node and a number associated with said port.

6. The telecommunications system of Claim 4, wherein said URL contains request information instructing said IN node to perform a task, said IN node sending response information to said web-capable machine via said http interface and said web browser after said IN node performs said task.

7. The telecommunications system of Claim 6, wherein said request information is an http request.

8. The telecommunications system of Claim 6, wherein said response information is a confirmation that said IN node performed said task.

9. The telecommunications system of Claim 6, wherein said response information is requested data.

10. The telecommunications system of Claim 9, wherein said requested data is displayed on a display of said web-capable machine using a markup language page created by said http interface.

11. The telecommunications system of Claim 6, wherein said request information is decoded by said http interface, said http interface determining the type of request and the type of data requested from said request information.

12. The telecommunications system of Claim 4, wherein said web browser provides a list of request information on said web-capable machine for selecting a given one of said request information, said given request information being sent to said IN node in said URL via said web browser and said http interface, said IN node obtaining response information based upon said given request information and sending said response information to said web-capable machine via said http interface and said web browser.

13. The telecommunications system of Claim 1 , wherein said web-capable machine is a computer.

14. A method for accessing an Intelligent Network (IN) node within a telecommunications system, said method comprising the steps of: enabling a web browser on a web-capable machine; and connecting, by said web browser, said web-capable machine to a hypertext transport protocol (http) interface associated with said IN node, said web browser accessing said IN node via said http interface.

15. The method of Claim 14, further comprising, before said step of connecting, the step of: opening, by said IN node, a port on said IN node to enable said web browser to access said IN node.

16. The method of Claim 15, wherein said port is a Transmission Control Protocol/Internet Protocol port.

17. The method of Claim 15, further comprising, before said step of connecting, the step of: entering on said web-capable machine, a Uniform Resource Locator (URL), said web browser using said URL to connect with said http interface.

18. The method of Claim 17 , wherein said URL contains a name associated with said IN node and a number associated with said port.

19. The method of Claim 17, wherein said URL contains request information instructing said IN node to perform a task, and further comprising, after said step of connecting, the steps of: performing, by said IN node, said task; and sending, by said IN node, response information associated with said task to said web-capable machine via said http interface and said web browser.

20. The method of Claim 19, wherein said request information is an http request.

21. The method of Claim 19, wherein said response information is a confirmation that said IN node performed said task.

22. The method of Claim 19, wherein said response information is requested data.

23. The method of Claim 22, further comprising, after said step of sending, the step of: displaying, on a display of said web-capable machine, said requested data using a markup language page created by said http interface.

24. The method of Claim 19, further comprising, before said step of performing, the steps of: decoding, by said http interface, said request information; and determining, by said http interface, the type of request and the type of data requested from said request information.

25. The method of Claim 17, further comprising, after said step of connecting, the steps of: providing, by said web browser, a list of request information on said web- capable machine; selecting, by said web-capable machine, a given one of said request information; sending, by said web browser, said given request information in said URL to said IN node via said http interface; obtaining, by said IN node, response information based upon said given request information; and sending, by said IN node, said response information to said web-capable machine via said http interface and said web browser.

26. The method of Claim 14, wherein said web-capable machine is a computer.