|
|
Andersen's L-Service |
|
| | Home | General IT consultancy | Directory consultancy | Directory education | X.500 | E.115 | Presentations | Contact | |
Warning: This section is still under developments and needs a lot of additions and some restructuring. As is is done in the author's spare time, it may take a while.
The latest edition of the ITU-T E.115 Recommendation may be found here
Page content:
This section is a tutorial type description of the ITU-T Recommendation E.115, Computerized Directory Assistance.
The Association for the European Interworking of Inquiry Services (EIDQ) is an association of Directory Assistance service providers, whose members cooperate to provide an international directory assistance service based on E.115.
Figure 1 - Directory Assistance principle
Figure 1 shows the basic principle of the traditional Directory Assistance (DA) service. In this example, a user in Denmark needs a telephone number in Italy. He calls the local Directory Assistance service provider, which subsequently connects to the Italian Directory Assistance database. After hopefully having retrieved the number, it is given to the user.
As also illustrated by the impatient user, response time and search efficiency are important. However, it is the operators efficiency that is most important. It is important to minimize the average time used for answering the user request, also called the average call handling time.
The directory business is rapidly expanding into what is called Electronic Directory (ED) Services where users - corporations, mobile phone users, etc. - access the directory information without operator assistance.
Operators and users directly accessing directory information are collectively called consumers.
Directory Assistance/Electronic Directory systems (or E.115 systems) are characterized by very optimized databases and efficient search engines. However, these aspects are not subject for E.115 standardization. Only the protocol used for the interchange of directory inquiries and replies is subject for standardization. This protocol is the basis for interworking among service providers.
An E.115 system is characterized by:
The first edition of ITU-T Recommendation E.115 was accepted and published by ITU-T in 1995. It was developed by EIDQ to ensure interworking among Directory Assistance service providers. In the time following 1995 the EIDQ produced a large number of supplementary specifications in the form of so-called questions. Some of these specifications clarified aspects of ITU-T Rec E.115 (1995), while others provided extension to cope with new service requirements. More than 60 such supplementary specifications were produced.
The 1995 edition of E.115 specified the use of an Open Systems Interconnection (OSI) protocol stack using the X.25 network. After some years it became clear that the use of an TCP/IP protocol stack would be more cost efficient and yet another supplementary specification was produced to replace the OSI stack with a TCP/IP stack.
Early in 2004 EIDQ decided to consolidate all their specifications together with the addition of some enhancements into a new edition of E.115. This new edition was approved as ITU-T Recommendation E.115 (2006).
The E.115 (2006) specifies two versions of the E.115 protocol.
Version 1 of the protocol covers the protocol as defined by E.115 (1995) and all the supplementary specifications that were approved up to the time when it was decided to produce a new edition. Version 1 of the protocol is expressed using the ASN.1 notation.
Version 2 of the protocol provides substantial enhancements over the version 1 protocol. In addition to the ASN.1 notation, this version of the protocol is also expressed using the XSD notation.
Figure 2 - E.115 service model
Figure 2 shows the basic principle of E.115. Each E.115 system is assumed to have an inquiring system and a replying system. If an inquiry is sent from System A to System B, it is sent from the inquiring system of System A to the replying system of system B using a dedicated connection for that purpose. The reply is returned on the same connection. If System B is to send an inquiry to System A, it uses a separate connection.
Figure 3 - Information structure
Figure 3 show the information structure of a database, as it looks from the outside. The information is seen as a number of listings, where each listing represents some type of entity relevant to store information about. However, the actual internal database structure may be very different. A listing consists of one or more fields, each of which holds a particular information item. The different types of listings are described in the following.
When the database is searched due to an inquiry message, information from relevant listings are returned in a reply. The information from a selected listing is called a selection. A selection may not necessity include all the fields of the corresponding listing.
The main information stored in the databases of E.115 systems is information about subscribers.
Communications addresses are the main information types a consumer wants to be returned from a directory service provider. A communications address is characterized by:
Version 1 of the protocol was originally designed only for telephone numbers, and uses the term subscriber number instead of communications address. If an e-mail or a URL is returned instead of a telephone number, it is indicated by a descriptive keyword. Other descriptive keywords are used for indicating services and characteristics without any clear separation between these two concepts.
Version 2 of the protocol have separate fields for type, service and characteristics with more complete sets of values.
If a communications address is not to be disclosed, the capital X'es are returned instead of the address.
Figure 4 - Character subset structure
Version 1 of the protocol had originally only support for a subset of the charracterset defined by ITU-T Rec. T.50, which is a 7-bit character set similar to ASCII. Later, optional support was added for latin 1 character set as defined by ISO/IEC ISO/IEC 8859-1.
Figure 5 - Filter concept
An inquiry has a number of fields. A majority of these fields are characteristics of the listing to be located. Each of these fields is called a filter item. The filter items together constitute the filter for the inquiry.
Each filter item is matched against the corresponding field of the listings in the database. If all the filter items match the corresponding fields of a listing, a selection of this listing is a candidate to be returned in the reply. Several listings may match the filter resulting in the return of several selections.
The number of filter items may be so few or so general that an excessive number of listings match the filter. In this case, a message code is returned indicating that more specific information is required.
A filter item may be truncated for different reasons. As an example, an operator may type only part of a city name to save key strokes. Operators are very skilled in entering efficient truncations. However, a service provider may have restrictions on truncation requiring a minimum length.
Matching may not always be performed using exact bitwise comparison between a filter item and the corresponding field of a listing:
The number of selections to be returned may be larger than it is reasonable to return in a single reply. If that limit is exceeded, the result must be split into pieces, called pages. Pages are numbered starting with zero.
Figure 6 - Paging
Figure 6 shows an example, where an inquiry produces n pages of results. As the inquiring system is probably not initially aware of the amount of data to be returned, it would not include any sequence number information and will then get page zero returned. Together with the page, the inquiring system will be informed that more data is available and how many selections were retrieved. Typically, the inquiring system would then ask for the next page, but it might instead ask for some other page. In the example, the inquiring system asks for page number 3.
In version 1 of the protocol, the length of a page shall be maximum 3000 octets, and it shall contain an integral number of selections. In version 2, a page shall consist of an integral number of selections up to some configural value. It is suggested that this value is set to 30.
If the number of pages are greater than 10, selections are not return and a message code indicates that the search should be better targeted.
Figure 7 - Hierarchical group
Some organizations may be represented by several listings having some hierarchical relationship possible reflecting the structure of the organizations. Figure 7 illustrates a simple example. The top level is called level 0, the next level is called level 1, etc.
The inquiring system may indicate how far down in a hierarchy a search shall be performed. If there is just one match within the hierarchy down to an including the indicated level, selections are returned for listings down to and including the same level.
The level of a listing is indicated in the returned selection. Version 1 uses a functional keyword for signalling the level. Version 2 has a special field for that purpose.
The functionality of the 1995 edition quickly turned out not to be sufficient for the directory assistance service providers. The concept of keywords was then invented. A keyword is transferred in inquiries and replies in fields that were already defined for allowing additional information to be transferred.
There are two kinds of keywords:
Keywords are not used in version 2 of the protocol. Instead the protocol has been extended with new fields to provide greater flexibility.
When a requester quotes a locality to be used for a subscriber search, the locality may not be completely correct. There may be several reasons for that, such as:
Figure 8 - Geographical expansion
When the quoted locality is not quite correct, the search may not locate the right subscriber. The operator may then extend the area for the search beyond the quoted location by asking for a geographical expansion. This illustrated quite stylistics by Figure 8. The inner circle labeled 0 represents the quoted locality. This is the area within which the subscriber initially searched. The the circle labeled 1 represents a geographical extension of level 1; the circle labeled 2 represents a geographical extension of level 2; etc.
In version 1 keywords and in version 2 a new inquiry field are used for specifying the wanted expansion.
X.500 has been extended to include so-called Mapping-based searches with a quite elaborate theory behind. This also includes geographical extensions.
Figure 9 - Proximity search
Every reply carries a message code that reports the outcome of the search, such as:
An XML Schema describes the structure of an XML document. The purpose of an XML Schema is to define the legal building blocks of an XML document (or message). An XML schema defines
There are two equivalent XML schema definition methods:
XSD is a specification is produced within the World Wide Web Consortium (W3C). It governs the encoding and decoding of XML documents. Its main advantage is that it is widely used and supported my many products. In addition, many tools are available.
ASN.1 is a set of specifications produced in cooperation between ISO/IEC and ITU-T. In contrast to XSD, ASN.1 defines several encoding techniques. The best known encoding is the Basic Encoding Rules (BER). For historical reasons, ASN.1 is in people minds often a synonym for the BER encoding. BER was for a while the only ASN.1 encoding rule and therefore used by early communications standards. However, ASN.1 has developed and is continuously been extended. Other encoding rules are available, such as the Packed Encoding Rules (PER) and, quite important, the XML Encoding Rules (XER). Tools are also available for this type of notation
Version 2 of the protocol is expressed both in ASN.1 and in XSD. Version 1 is expressed only in ASN.1 and can only use BER encoding. The ITU-T ASN.1 Module Database has made available the ASN.1 modules for version 1 and version 2. The ITU-T XSD database has made available the XSD specification for version 2.
Without any special adaptation, an ASN.1 specification will produce an XML encoding having a structure equivalent to the ASN.1 specification using only XML elements. But by adding complementary specifications to the ASN.1 module specific components (fields) of the ASN.1 can encoded as XML attributes. There are other similar specification tools that allows the same possibilities as within XSD. Accordingly, ASN.1 and XSD are equivalent XML schema definitions.
Figure 10 - ASN.1 and XSD compatibility
The ASN.1 and the XSD specifications are equivalent for version 2 in the sense that there is no difference between XML documents produced according to either of these specifications. Figure 10 illustrates this. A message (an XML document) crated based on the ASN.1 specification using an ASN.1 tool and XER encoding can be received an parsed by a XSD tool at the other end be proved to be accordance with the corresponding XSD specification. Likewise can an XML document created at the right side may be parsed and accepted by the left side. There is no way of telling whether an XML document was created using ASN.1 or XSD.
More information on this may be found here and here. More about the extended XER encoding rules can be found here.