NICC ND 1615 V1.1.1 ( )

Transcription

1 1 Document NGN Interconnect; Voice Line Control Service; General Connectivity Management 2009 Ofcom copyright NOTICE OF COPYRIGHT AND LIABILITY Network Interoperability Consultative Committee, Ofcom, 2a Southwark Bridge Road, London, SE1 9HA.

2 2 Copyright All right, title and interest in this document are owned by Ofcom and/or the contributors to the document unless otherwise indicated (where copyright be owned or shared with a third party). Such title and interest is protected by United Kingdom copyright laws and international treaty provisions. The contents of the document are believed to be accurate at the time of publishing, but no representation or warranty is given as to their accuracy, completeness or correctness. You may freely download, copy, store or distribute this document provided it is not modified in any way and it includes this copyright and liability statement. You may not modify the contents of this document. You may produce a derived copyright work based on this document provided that you clearly indicate that it was created by yourself and that it was derived from this document and provided further that you ensure that any risk of confusion with this document is avoided. Liability Whilst every care has been taken in the preparation and publication of this document,, nor any committee acting on behalf of, nor any member of any of those committees, nor the companies they represent, nor any person contributing to the contents of this document (together the Generators ) accepts liability for any loss, which may arise from reliance on the information contained in this document or any errors or omissions, typographical or otherwise in the contents. Nothing in this document constitutes advice. Nor does the transmission, downloading or sending of this document create any contractual relationship. In particular no licence is granted under any intellectual property right (including trade and service mark rights) save for the above licence to copy, store and distribute this document and to produce derived copyright works. The liability and responsibility for implementations based on this document rests with the implementer, and not with any of the Generators. If you implement any of the contents of this document, you agree to indemnify and hold harmless the Generators in any jurisdiction against any claims and legal proceedings alleging that the use of the contents by you or on your behalf infringes any legal right of any of the Generators or any third party. None of the Generators accepts any liability whatsoever for any direct, indirect or consequential loss or damage arising in any way from any use of or reliance on the contents of this document for any purpose. If you have any comments concerning the accuracy of the contents of this document, please write to: The Technical Secretary, Network Interoperability Consultative Committee, Ofcom, 2a Southwark Bridge Road, London SE1 9HA.

3 3 Contents NGN Interconnect; Voice Line Control Service; General Connectivity Management...1 Intellectual Property Rights...5 Foreword...5 Introduction Scope References Normative references Informative references Definitions and abbreviations Definitions Key Words Abbreviations Document Structure PLANNING VLC Route Planning VLC Route Planning Supported VLAN Sizes Sizing of VLC VLANs Signalling VLANs VLC Media VLANs Relationship between Signalling and Media Route Sizes Detailed Signalling VLC VLAN SIZING Detailed Media VLAN Bandwidth Sizing FULFILMENT Information exchanged prior to service establishment General Background Transmission and Transport General Connectivity (EP) VLC Specific Attributes Examples of naming VLC Service Order Scenarios Security arrangements ASSURANCE IP Media Border Function isolation Overload Protection Mechanisms Traffic Overload Registration Overload Graceful Removal of Traffic Overview Graceful removal of traffic from a VLC Route Graceful removal of traffic from a Media VLAN Graceful removal of traffic from a Signalling VLAN Graceful removal of traffic from MBF, ESCF or SBF Fault Handling Fault Categorisation Examples of Faults Monitoring and reporting of Call Quality Statistical Reporting... 22

4 4 8 ACCOUNTING AND SETTLEMENT Retail Billing Wholesale Billing Start of Charging Accuracy of Call Release A.1 Background A.2 WBCC and WVC Terms A.3 WBCC/WVC Service Description A.4 Null A.5 WBCC/WVC Planning A.5.1 General A.5.2 Offered VLAN Sizes A.6 WBCC/WVC Fulfilment A.6.1 General A.6.2 Dialplans A.6.3 Ordering Process A.7 WBCC/WVC Assurance A.8 WBCC/WVC Accounting and Settlement History...28

5 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs which are, or may be, or may become, essential to the present document. Foreword This Document (ND) has been produced by TSG/Management. Introduction NGN interconnect management processes are those processes that are required to plan, establish and operate an NGN interconnect, and account for its usage. They are additional to the processes and procedures for actually using the interconnect. This document identifies the processes, and associated data, needed to maintain operability of a Voice Line Control (VLC) service across a Next Generation Network, Multi-Service Interconnect.

6 6 1 Scope The scope of this specification is restricted to the management aspects of Green Release VLC interconnect. The architecture and specification of VLC service sessions are specified in [2], and the protocol and procedures for establishment of such sessions are defined in [3]. This document specifies management activities that require co-ordination between the VLC-Provider and the VLC- User, who between them operate the VLC interconnect. The functional interaction between the VLC-Provider Network and the VLC-User Network does not have a peer-to-peer symmetric relationship, and the management relationship between them is likewise not symmetric in all aspects. The VLC service interconnect makes use of lower layer transport connectivity. For management activities relating to the Transport Connectivity layer see [4]. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document; - for informative references. For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case letters. 2.1 Normative references NOTE: While any hyperlinks included in this clause were valid at the time of publication cannot guarantee their long term validity. [1] SR ; ETSI Drafting Rules Section 23:- Verbal Forms for The Expression Of Provisions [2] ND1620 Interconnect Architecture for Voice Line Control Service between UK Next Generation Networks [3] ND1021 Voice Line Control for UK Interconnect using TISPAN IMS-based PSTN/ISDN Emulation [4] ND1613 NGN Interconnect; Transport Service Layer Management [5] ND1628 Signalling Security [6] ND1636 IP Address Allocation

7 7 2.2 Informative references [7] ND1423:2007/6 Guidelines for Usage of Enbloc / Overlap Signalling in UK networks 3 Definitions and abbreviations 3.1 Definitions This document inherits the terms defined in ND1620 [2]. In addition, and for clarity, the following terms apply: Term (Abbreviation) (VLC) Media Route (VLC) Signalling Route VLC Route VLC Routeset Signalling VLAN Media VLAN VLC End User Explanation The managed bandwidth between paired peer Media Border Functions, carrying VLC media traffic (only). The communication pathway, carrying signalling between AGCF and USCF, passing over a specific VLC-Provider ESCF and VLC- User ESCF. Where SCTP multi homing is used the VLC Signalling Route may pass over more than one SBF pair and MSIL. Otherwise the VLC Signalling Route will pass over a specific SBF pair and MSIL. A VLC Signalling Route is associated with a single VLC Media Route. The unique combination of a VLC Signalling Route and associated VLC Media Route. Unavailability of either component results in the unavailability of the VLC Route. A prioritised sequence of VLC Routes. The component VLC Signalling Routes form a Signalling Path. A given VLC End User will be assigned to a VLC Routeset. A VLAN between VLC-Provider SBF and VLC-User SBF carrying (paths of) one or more VLC Signalling Routes. (NB: as per ref [2] a Signalling VLAN is reserved for VLC signalling only.) A VLAN between VLC-Provider MBF and VLC-User MBF carrying one or more VLC Media Routes. There are unexplored issues with having more than one VLC Media Route across a particular VLAN, and implementations may restrict the number to one. The individual line end user serviced by the VLC-User across the VLC service interconnect. Note: The use of brackets around VLC in terms above signifies that ND1620 uses the term without the VLC, but the term is used with VLC in this document, to highlight that the relevant entity is specific to VLC service. 3.2 Key Words The key words shall, shall not, must, must not, should, should not, may, need not, can and cannot in this document are to be interpreted as defined in the ETSI Drafting Rules [1]

8 8 3.3 Abbreviations For the purposes of the present document, the abbreviations given in ND1620 [2] and the following apply: CDR CP ETSI GNP IP ISDN NGN NIPP PSTN QoS RTP SIP SIP-I TISPAN URI VLAN VLC Call Details Record Communications Provider European Telecommunication Standards Institute Geographic Number Portability Internet Protocol Integrated Services Digital Network* Next Generation Network Network Information Publication Principles Public Switched Telephone Network* Quality of Service Real-time Transport Protocol Session Initiation Protocol SIP with encapsulated ISUP Telecoms & Internet converged Services & Protocols for Advanced Networks Uniform Resource Identifier Virtual Local Area Network Voice Line Control * PSTN and ISDN when used with the term service defines the replication of the service set applied to NGNs rather than the legacy networks themselves. 4 Document Structure The VLC Service provides a Connectivity Layer capability. It makes use of the same underlying transport functions that support other Connectivity Layer services, such as the PSTN/ISDN Generic Connectivity Layer. In turn, the VLC Service Connectivity Layer provides capabilities on which a number of Product Layer services can be built. Examples of Product Layer services which can be built using the VLC Connectivity Layer are PSTN end user service and Virtual Private Network service (including private dial plan). No interconnect management interactions are defined for Product Layer services, as offerings at this layer are not interconnect services and so are a private matter for the VLC-User. All provide, operate and other management actions between VLC-Provider and VLC-User will take place at the VLC Connectivity Layer or below. This is represented in a number of functional layers as shown in figure 1. The Transmission Layer provides physical connectivity based on various transmission technologies, e.g. SDH and Ethernet Physical. The Transport Capability Layer offers a number of transport types with various characteristics, e.g. TDM, ATM, and IP to the services they support. e.g. PSTN User service, VPN e.g. Registration groups, Signalling Associations e.g. IP over Ethernet VLAN, TDM, ATM Etc. e.g. SDH / Ethernet Physical Figure 1:- Layering of functions for VLC over a Multi-service Interconnect Figure 2 shows VLC interconnect functional layers overlaid with the broad areas of management activity. This document is concerned with the management activities at the VLC Connectivity Layer. For management areas related to the Transport Capability Layer see [4].

9 9 The section of this document where the management area is addressed is indicated in figure 2. Figure 2:- Structure of NGN VLC Interconnect Management areas Note for clarity; [4] in figure 2 is a reference, not a section in this document. The numbers 5, 6, 7 and 8 refer to sections in this document. 5 PLANNING 5.1 VLC Route Planning VLC Route Planning Multiple VLC End Users may be grouped into a single Registration_Group to allow a single registration message to register the whole group, and so reduce the possibility of a registration message overload. VLC End Users can only be allocated to the same Registration_Group when they possess the same characteristics, including the host AGCF and VLC Routeset. The VLC-Provider may limit the size of a Registration_Group. Registrations for the Registration_Group will be sent from the AGCF to the controlling USCF across the VLC Signalling Route of the highest priority VLC Route available in the VLC Routeset. A VLC-Provider may restrict the number of VLC Routes within a VLC Routeset. The VLC-Provider may impose limits on the number of VLC End Users which can be assigned to a given VLC Routeset. For example, the number of VLC End Users which can use a given VLC Route as highest priority may be limited based on the bandwidth available in the associated VLC Media Route. When planning VLC Routesets, VLC-Users should consider how traffic might be redistributed in the event of failure of a component of the VLC Routeset. Such failures include failure of Signalling or Media VLANs, or of SBF or ESCF. (Note: if using multi-homed SCTP then a VLC Route can be resilient against failure of Signalling VLAN or SBC.) Consideration should be given to the availability of both Signalling and Media capacity to carry the redistributed traffic. Two possible strategies are identified: Installation of one or more spare VLC Routes, which are not themselves primary VLC Routes in any VLC Routeset, but which would be specified as alternative VLC Routes in VLC Routesets. If such an approach is taken, then care should be taken that such VLC Routes are actually available when needed, because with carrying no traffic in normal circumstances it could be that failures on them are not detected. Assigning some test lines to these VLC Routes with periodic test calls could avoid this possibility. Leaving spare capacity on several VLC Routes, and ensuring that VLC Routesets have these VLC Routes as second (or third) choice. To avoid overloading one of these routes in a failure condition, the VLC Routesets having a given VLC Route as first choice should have a variety of VLC Routes as second choice. This will require careful planning. Modelling of the network failure scenarios may assist the planning activity. A combination of these may be possible. 5.2 Supported VLAN Sizes The VLC-Provider may provide only a restricted set of Signalling VLAN and Media VLAN sizes. The VLC-Provider shall publicise what VLAN sizes it supports. The Signalling VLAN size required will be dependent on the nature of the traffic and the number of calls which can be carried across the available media, itself determined by the Media VLAN size. In practise the VLC-Provider may chose to make the Signalling VLAN size unique for a given Media VLAN size, e.g. determined by a fixed ratio of VLAN sizes.

10 Sizing of VLC VLANs Signalling VLANs Signalling VLANs are provided between Signalling Border Functions, and carry one or more VLC Signalling Routes between the SBFs and, by extension, between AGCF and USCF. The VLC-User shall be responsible for planning the dimensioning of Signalling VLANs (because only the VLC-User is aware of the intended use of the service, and hence the expected bandwidth). The VLC-Provider may monitor Signalling VLAN usage and report where usage exceeds recommended thresholds. A signalling VLAN shall be dimensioned to carry all of the signalling for the VLC Routes that it may support given the traffic distribution discussed in section Where multi-homed SCTP is used across more than one Signalling VLAN, each Signalling VLAN shall be dimensioned to carry the full SCTP association signalling load VLC Media VLANs It is the responsibility of the VLC-User to correctly dimension Media VLANs. The VLC-Provider may monitor Media VLAN usage and report where usage exceeds recommended thresholds Single Media VLAN between CPs Where this is the only connection between CPs, this VLAN shall be dimensioned to carry all the traffic flowing between the CPs. In this scenario, the lack of media resilience shall be given consideration Multiple Media VLANs between Media Border Functions Where a VLAN is one of two or more VLANs all terminating on different combinations of Media Border Functions, each VLAN shall be dimensioned according to planning rules to carry the traffic flowing between these Border Functions. E.g. one Media VLAN should be dimensioned to carry its own traffic and, potentially, some or all of the traffic from a failed VLAN, according to the resilience planned identified in section Relationship between Signalling and Media Route Sizes In planning VLC interconnect, the number of VLC End Users will determine the maximum number of concurrent sessions required, using some assumptions about the nature of the service, calling pattern, and congestion levels. The maximum number of concurrent sessions determines the size of the Media VLAN required. The number of VLC End Users, or alternatively the number of concurrent sessions, influences the Signalling VLAN bandwidth required, although in the case of signalling more factors are involved. Factors affecting Signalling VLAN sizes are discussed in section It will be noticed that there are large variations in the signalling bandwidth required, dependent on the call scenario, the nature of the end user service and the required resiliency. The call scenario may influence the signalling per average call, for example in requiring the use of overlap signalling. The volume of calls per user is highly dependent on the nature of the service, which also influences the average call hold time. Despite this variability, in practical VLC interconnect planning it is likely that VLC-Users will fix the Signalling VLAN size based on the Media VLAN size. Because of the variability of the signalling required for various call scenarios, normative information cannot be specified for the sizing of Signalling VLANs for given Media VLAN sizes. For an indicative guide, see Annex B Detailed Signalling VLC VLAN SIZING Introduction A study has been undertaken in order to evaluate the required bandwidth of the SIP (VLC) signalling over an interconnect link between two communications providers. The main factors that determine the required bandwidth for signalling are: The length of the SIP (VLC) messages for call setup and clear-down;

11 11 The number of messages per call; The number of non-call related messages; The length of the lower layer headers; The peak calling rate (calls/second) the signalling path is required to support; The frequency of recourse to overlap signalling; The scaling factor K (mean to peak calling rate variability); and The acceptable signalling dimensioning utilisation r. Other factors to consider for signalling dimensioning are: reliability, security, survivability, and future expansion. Of interest but not contributing to the magnitude of signalling per call, is the call hold time. There is a proportionate dependency on calling rate and call hold time in determining the media bandwidth requirement. Or in other words, for a given media bandwidth the maximum signalling bandwidth is required when the call hold time is at a minimum Discussion Within the ITU E.733 recommendation, dimensioning of SS7 TDM signalling links is discussed. Although SIP signalling messages differs greatly from those of SS7, the principles of network operation remain. Calls are established, controlled and cleared in response to specific messages. The activity and calling patterns of subscribers is independent of the underlying network technology. Our analysis of signalling for NGN interconnect of nodes uses the fundamental principles described in the ITU recommendation, but tailored with the following. The lengths of SIP (VLC) messages have been measured in a model environment and are summarized later in this document. Their length, type and number per call are added to the transport layer overheads to determine actual signalling bandwidth per call. The calling rate is a variable in the calculations. It is used in combination with call hold times to determine the number of calls that a given bandwidth can support. A scaling factor K is also applied to calculations to account for the variability in calling rate over and above a stationary Poisson traffic distribution. Typically this rate factor is between 1.08 and Signalling links should be dimensioned so that the link utilization, r, does not exceed a maximum utilization, rmax. This constant is derived by taking into account, normal and extreme error conditions, and transients when paths swap due to failures. Determining the rmax is achieved with knowledge of the network together with end node performance. For example some equipment will happily run at 50% utilisation but suffers performance and delay degradation at 80%. In our experience most signalling implementations will operate at 40% load with no performance degradation allowing for a variability of K, (actual vs. Poisson). Thus rmax would normally be set at 40%. This would be attained if one of two signalling paths had failed in a resilient (dual path) connection. Normal setting for r is therefore 20% (0.2) SIP (VLC) Messages for a basic call. The setup and clear-down messages for a successful basic call with release by the calling customer will be as follows: Forward INVITE Backward 100 Trying Backward 180 Ringing Forward PRACK Backward 200 OK (to the Prack) Backward 200 OK (to the Invite) Forward ACK * Forward BYE Backward 200 OK (to the Bye). *Additional messages may also be exchanged on long call hold times as an activity test. The actual interval of these is network and vendor specific, but typically the following keep alive sequence is exchanged to check the state of the call.

12 12 INVITE 200OK ACK The typical content for each of these messages is shown in table 5-1. In these examples the domain names in various fields are typical rather than the maximum agreed by. Table 5.1 shows message lengths for both the typical and maximum length domain names. The examples also show typical lengths for the following fields: branch To and From tags Call-ID Cseq These fields do not have an absolute maximum length. In table 5.1 the message lengths shown are for the typical length of these fields and the extra length if the typical length of the above fields was to be doubled Impact of Overlap Signalling Where the dialplan allows a variable length numbering plan, overlap signalling may be used. Overlap signalling can only occur on calls outgoing from the VLC line: never on calls to the VLC line. Overlap signalling increases the average number of messages per call. Alternatively, this can be thought of as increasing the number of call attempts (of shorter message dialogues) per successful call. Where overlap signalling is required, the VLC-User will return a 484 Address Incomplete message, identifying the minimum number of extra digits to be sent in a subsequent Invite. This message exchange increases the total forward message bytes by a typical 1218 (1356 with headers) and in the backwards direction by 300 bytes (438 with headers). Where one extra digit is requested in each 484 message, an extra Invite and 484 Address Incomplete message may be sent for each extra digit. In such cases, and where a digit-by-digit dialplan has been used and an 11 digit number is dialled, the total bytes needed will be a typical bytes (including headers) in the forward direction, and 7635 bytes (including headers) in the backward direction, i.e. an over 5-fold increase in the forward direction. Overlap signalling should therefore be avoided. Overlap signalling can be avoided on a PSTN service by suitable choice of dial-plan. For non-pstn service overlap signalling may be unavoidable, but because such a service would be of a proprietary nature the consequences to signalling bandwidth cannot be accounted for in this document. Therefore, the signalling bandwidth calculations in this document assume that overlap signalling is not used. For guidance on the use of overlap signalling, see [7] Non-Call Related Signalling Non-call related signalling includes facility activation and registration. Facility activation (e.g. *21* to activate a call divert) are not accounted for in this document for two reasons: they occur sufficiently infrequently not to overly affect the calculations; and for the most part they can be considered to have the signalling bandwidth impact of an ordinary call. User registrations will occur only once each half hour, and will register a group of (optimally) 30 end lines. The impact of registration messages is therefore low, and not further accounted for in this document Lower layer headers The assumption has been made that SCTP/IP will be used. The SCTP header is 28 octets per message and the IP header is 20 octets per message. Additionally the LLC and MAC headers are 14 octets per message. For each of these headers a total in the forward and backward directions is shown in the following table.

13 Message Lengths Message Forward Message lengths (Typical) Forward message lengths with max length Domain names + for branch, tags, Call-ID, & Cseq Backward Message lengths (Typical) Backward Message lengths with max length Domain names + for branch, tags, Call-ID, & Cseq (Note 1) (Note 2) (Note 3) (Note 4) (Note 2) (Note 3) (Note 4) INVITE Trying Ringing PRACK OK (Prack) OK (Invite) ACK BYE OK (Bye) number of msgs= SCTP Headers/msg (28) Ipsec/msg (72) IP Headers/msg (20) LLC+MAC Hdrs/msg (18) Sub Totals Total forward Total backward Table 5-1 Signalling message lengths Note 1: These are the SIP messages for a basic Pots call and the extra lower layer headers. Note 2: The numbers shown in the Forward and Backward columns are the lengths of typical messages. It is likely that the messages could be longer than this (see Notes 3 and 4 below). Note 3: The numbers in this column represent the message lengths due to use of maximum length domain names (63 octets element i/d & 20 octets provider ). Note 4: There are some parts of messages that do not have a definite maximum length. The numbers in this column represent the extra length (compared to the example messages) due to increase in size (doubling) of the variable part of: the branch parameter, the Call-ID and Cseq headers, and doubling of the length of the From and To tags. It is assumed that this doubling will be adequate to represent the longest likely to be encountered, but this may not be the case

14 Signalling to Media Bandwidth Relationship Average call hold times (acht) is a key factor in determining the Signalling VLAN bandwidths required, as can be seen in the table below. Signalling bandwidth is dependent on the nature of the service being offered, and the expected use of that service. The following table is offered for guidance, based on typical PSTN service usage. Media Bandwidth (Mbyte) Maximum simultaneous calls Signalling Bandwidth normal calls (3 min acht) (Byte) Signalling Bandwidth for televote (acht ~6s ) (Byte) 1 Not recommended Not recommended Not recommended Not recommended Table 5-2 Indicative Media and Signalling VLAN Bandwidths Note: A Signalling VLAN may carry VLC Signalling Routes for many VLC Routes, and the VLC Media for these VLC Routes may traverse many MSILs. Hence the total media bandwidth may exceed 800MB, and hence the signalling bandwidth may be required to be greater than the maximum in this table. The percentage of overlap signalling will also be significant, in that it introduces a requirement for higher signalling bandwidths. VLC-Users shall account for the usage of overlap signalling in determining the signalling bandwidth required. Actual signalling bandwidth required may need to be modified based on testing and live experience Detailed Media VLAN Bandwidth Sizing Bandwidth Requirements per Call The bandwidth required by a media stream depends on the packet size, the speech codec bandwidth requirement, and the overhead of the various headers required to transmit the packet. The header overhead depends on the layer of the protocol stack at which the bandwidth is to be measured, e.g. whether at IP, VLAN or Ethernet layer. At the IP layer the header overhead bandwidth per packet is 40 bytes, or 320 bits. This is comprised of IP (20 bytes), User Datagram Protocol (UDP) (8 bytes), Real-Time Transport Protocol (RTP) (12 bytes). (Assuming use of IPv4.) At the Ethernet VLAN layer each packet requires an additional 22 bytes, which added to the IP header overhead gives an additional 62 bytes (496 bits) over and above the raw codec information. This assumes the most commonly used definition VLAN size.

15 15 At the Ethernet layer an further 20 bytes must be added per IP packet giving a total of 82 bytes (656 bits) over and above the raw codec information. With these assumptions, the bandwidth required for a call with base codec bandwidth B kbps, and packetisation at P ms is: B + 320/P kbps at the IP layer B + 496/P kbps at the VLAN layer B + 656/P kbps at the Ethernet layer For G.711 at 10ms packetisation rate, these equate to: 96 kbps at the IP layer kbps at the VLAN layer kbps at the Ethernet layer Planning Guidelines When planning how many media streams may be allowed over a given VLAN size (or alternatively, when planning how large a VLAN must be for a given number of media streams) some overhead must be added on top of the VLAN bandwidth assumed by the sum of the media streams. For smaller VLAN sizes (<30Mbps) the use of shapers is assumed, and the constraint on fill is determined by the need to keep jitter below 2ms and packet loss below 10-9 (this latter being the maximum permitted packet loss to emulate ISDN service). This can be modelled by a N*D/D/1 queue. For larger VLAN sizes (>=30Mbps) shapers have less impact (and need not be used), and the maximum fill is determined by the sum of all media streams, to a maximum fill of 98%. That is: Max_sessions = INT(0.98 * VLAN_size * P / (B.P + 496) ) For 10ms this equates to: Max_sessions = INT(0.98 * VLAN_size / 113.6) In both cases VLAN_size being measured in kbps. Equivalently, for 10ms and with VLAN_Msize measured in Mbps, this can be expressed as: Max_sessions = INT(VLAN_Msize * 8.627) For VLAN sizes up to 200Mbps this is summarised in the following table: VLAN size (Mbps) Max. permitted no. sessions VLAN size (Mbps) Max. permitted no. sessions

16 16 To calculate the base Ethernet port bandwidth consumption for a given VLAN size, the additional Ethernet headers must be taken into accounted. Assuming 10ms, this can be calculated from the ratio of the packet sizes at the Ethernet layer (162 kb) and at the VLAN layer (142 kb), giving: VLAN_layer2_bandwidth = * VLAN_size. The Ethernet bandwidth can be related directly to the maximum number of sessions by: Max_sessions = INT(VLAN_layer2_Mbandwidth * 7.567) Where VLAN_layer2_Mbandwidth is measured in Mbps, and for media sessions using 10ms. Please note when calculating the Ethernet bandwidth, that not all sizes of VLAN need be offered across NGN interconnect. These calculations do not account for the use of RTCP, except in the allocation of 2% extra headroom on VLAN sizes above 30Mbps. 6 FULFILMENT 6.1 Information exchanged prior to service establishment This section identifies information which may be exchanged between VLC-Provider and VLC-User prior to VLC service establishment. A subset of this information may also be exchanged prior to changing details of the interconnect (for example, bandwidth requirements) General Background Item Item Item Company name and address Contact (name, address, phone, mobile, ) details for: Commercial, Technical, Operational, Fraud & Security, Billing queries. Ready for service target date Transmission and Transport These aspects are covered in ND1613 [4] General Connectivity (EP) Item Item Interconnect equipment configuration details Type, model, build and location of the point of handover for the Edge Session Control Function. Type, model, build and location of the point of handover for the IP Media Border Function Type, model, build and location of the point of handover for the Signalling Border Function Note Location information may be withheld for security reasons. Interconnect configuration approval test Has configuration been type approved for interconnection? Name of Approver Date of approval Constraints on approved use

17 17 Item Item Item Item Use of Transport layer Mapping of IP subnet/vlan(s) to transmission infrastructure identifiers (e.g. fibre numbers) as listed in ND1613 [4]. Mapping of signalling to IP subnet / VLAN(s) Mapping of media to IP subnet / VLAN(s) IPSec information exchange for Signalling VLANs. Refer to [5] for information to be exchanged for IPSec. Addressing Information Agreement on who is providing IP addresses (See [6]). SIP and RTP port ranges SIP URI to IP mapping P-Charging-Vector (including Originating Inter-Operator Identifier and icid-gen-addr). Media characteristics Voice codec and packet size DTMF digit transport mechanism (currently only in-band) Support of T.38 or V.150 required (currently not supported) Silence suppression used (currently not supported) Protocol support SIP transport protocol and version SIP profile supported. IPsec profile supported. RTCP verson supported. Item Other technical information Method of supporting call rate limitation. See section 7.2. Extent of use of overlap signalling VLC Specific Attributes Item Item Items required for AGCF set up. (Group, Route) Product name / code Date required Domain name (e.g. vlc.cpname.uktel.org.uk) Private ID (username) (i.e. the SIP username, e.g. service1@vlc.cpname.uktel.org.uk) Serving MSAN (e.g. as extracted from NIPP) Registration/authentication key (SIP password) Prioritised list of voice EPs. Voice End User Access (VEUA) SIP configuration parameters Voice configuration parameters (Domain name, Public ID) (Line type (e.g. Earth calling, loop calling, loop calling PBX, earth calling PBX, DEL), Telephony Priority Service, Line Reversal, Hotline/warmline Indicator, Caller display) Access order parameters, address or existing Phone number (possibly physical line characteristics). Dial plan. Registration Group is returned from the VLC-Provider, in the form of the Temporary Public ID the VEUA has been allocated to. Note 1: VEUA facilitates the configuration of VLC End User data on both the Access Gateway Control (AGC) and the Access Gateway (AG) Note 2: accurate identification of an end user access is not always guaranteed. While the end user has PSTN service from the VLC-Provider, a combination of address and PSTN DN is sufficient to identify the line. When the end user has PSTN service from a VLC-User, postal address plus PSTN DN may be sufficient to identify the line, provided the mapping exists in the VLC-Provider s support systems. When the end user has no PSTN service (for example, when the user has cancelled service for some time, or where the user has a non-pstn service) a combination of postal address, last known PSTN DN, last known Public Id, and other relevant information (such as Kilostream identifier) may

18 18 be sufficient to identify the line. Where the end user line cannot be identified, a VLC-User may have no option other than to order a new line to the premises through the VLC-Provider. Item VLC Product Usage Characteristics Capacity forecasts (including capacity required for Priority service). 6.2 Examples of naming Temporary Public ID (identifies registration group, assigned by VLC-Provider) bt.msan1134.1@vlc.cp2.uktel.org.uk (NB the.1 indicates the registration within the registration group) Public ID (identifies individual lines, allocated by VLC-User) @vlc.cp1.uktel.org.uk Cust @vlc.cp2.uktel.org.uk Joe.a.bloggs@vlc.cp3.uktel.org.uk Route ID (SIP URI) Vep3.msil2.cp1.uktel.org.uk Sbc23.if2.cp2.uktel.org.uk 6.3 VLC Service Order Scenarios Prior to full establishment of VLC service end users may be on one of many available services. There are correspondingly many order scenarios transferring an end user from the existing service to the VLC provided service. Following full establishment of VLC service, when all end users are served by VLC, two scenarios exist in which the VLC-User can order a VLC line from the VLC-Provider. These differ on the state of the line before the order: 1. Provision of a new line, with VLC; 2. Transfer of line control from an existing VLC-User network. In the latter scenario the PSTN number associated with the line will often be transferred along with the line, using Geographic Number Portability (GNP): 3. Transfer of line and PSTN number. When transferring the PSTN number the usual case is that the current VLC-User network hosts the number. Where this is not the case the VLC line transfer and the GNP number transfer are regarded as two separate processes, and coordination of the two processes is the responsibility of the new VLC-User. Where the current VLC-User is hosting the PSTN number, that VLC-User will often be the Range Holder for the number, but in the general case the Range Holder may be another party. Thus, in the general case, four parties are involved in transfer of a VLC line with associated PSTN number: VLC-Provider, Old VLC-User (and exporting CP), New VLC-User (and importing CP), Range Holder. In this transfer scenario the business process design should aim to synchronise the VLC line transfer process and the GNP process such that the duration in which incoming calls cannot be delivered is minimised. 6.4 Security arrangements The document Signalling Security across NGN Interconnect [5] requires the use of IPSec on Signalling VLANs across NGN MSILs, except in certain circumstances, as defined in [5]. The document Signalling Security across NGN Interconnect [5] defines:

19 19 The characteristics of the IPSec security used on the Signalling VLAN. The IPSec parameters to be exchanged on establishing NGN interconnect. The frequency of key renegotiation. For fuller information on security arrangements refer to [5]. 7 ASSURANCE 7.1 IP Media Border Function isolation ND1620 [2] identifies scenarios where a VLC Media Route terminated by the Media Border Function cannot be used, and the consequence on receipt of a SIP request (being a SIP 503 response). From an interconnect management perspective, the receipt of a 503 response should be reported via an alarm. If a subsequent SIP Invite is successful, the alarm should be cleared. Persistence of 503 responses should raise the severity of the alarm, and operational intervention may be needed to correct the fault. 7.2 Overload Protection Mechanisms Traffic Overload The Media Stream (it4b) [2] is protected from overload by the Bandwidth Management Function, and hence the IP Media Border Function is also protected from overload (assuming correct dimensioning). Although Bandwidth Managers may protect Edge Session Controllers from having to control too many simultaneous sessions, the limiting factor for an Edge Session Controller is not normally the number of simultaneous sessions, but rather the rate at which sessions are set up, i.e. the rate at which Invites are received. The Signalling Border Function may provide some protection against such signalling overload, but this is not one of its intended functions, and most Signalling Border Elements will transport more traffic than the Edge Session Controller can handle; further a single Edge session Controller may receive traffic from several Signalling Border Functions. The VLC-Provider s and VLC-Users ESCFs shall limit call rates using static methods, limiting traffic to a rate which the ESCF is dimensioned to reliably carry. Use of a dynamic traffic rate limitation mechanism is for further study Registration Overload An excessive volume of user registrations is another possible source of overload, particularly following AGF or AGCF restart. The VLC-Provider shall take appropriate measures to avoid registration storms. These should include the use of Registration Groups, as defined in [2] and [3], and may involve other means, such as the staggering of initial and periodic registrations. 7.3 Graceful Removal of Traffic Overview For operational reasons it may be necessary to remove traffic from a network component before performing a maintenance action on that component. In doing so it is desirable to avoid interruption to existing calls, allowing them to continue to end-user initiated release, while at the same time preventing new calls from traversing the network component. Network components which may require the graceful removal of traffic include: A VLC Route. A Media VLAN.

20 20 A Signalling VLAN MBF, ESCF or SBF Graceful removal of traffic from a VLC Route VLC-Provider initiated Traffic Removal For the VLC-Provider to achieve graceful removal of traffic from a VLC Route, the VLC-Provider shall prevent registrations from passing over the VLC Route, forcing them to be sent instead over an alternative VLC Route. Existing calls shall be maintained and new calls will be possible over the existing VLC Route until the registration period expires. At such time the AGCF will register each affected Registration Group over the second (or third) choice VLC Route. Once registration for a Registration Group is successful, new calls for this Group will be setup over the new VLC Route. Calls over the previous VLC Route will remain on that Route until they clear down. Traffic using the VLC Route shall be allowed to decay for a time Tdecay, after which traffic still using the connection may be cleared. Following expiry of timer Tdecay remaining calls should be examined to check they are not life-line calls. This may be done manually, and may be assisted by the VLC-User. The remaining calls may be cleared by using the procedures for call release defined in [3] VLC-User initiated Traffic Removal For the VLC-User to achieve graceful removal of traffic from a VLC Route, the VLC-User shall stop responding to SIP Option messages on the VLC Route. This will cause the VLC-Provider to initiate a re-registration of affected Registration_Groups across the VLC Route. The VLC-User shall not respond to the registration, or repeat attempts on this VLC Route. This will cause the VLC-Provider network to re-register across alternative VLC Routes. Once registration for a Registration Group is successful, new calls for this Group will be setup over the new VLC Route. Calls over the previous VLC Route will remain on that Route until they clear down. Traffic using the Route shall be allowed to decay for a time Tdecay, after which traffic still using the connection may be cleared. Following expiry of timer Tdecay remaining calls should be examined to check they are not life-line calls. This may be done manually. The remaining calls may be cleared by using the procedures for call release defined in [3] Graceful removal of traffic from a Media VLAN To remove traffic from a Media VLAN, traffic can be removed from all the VLC Routes whose VLC Media Routes use that Media VLAN. This shall be achieved using the mechanisms described above. When this is complete the Media VLAN may be removed from service Graceful removal of traffic from a Signalling VLAN Where a VLC Signalling Route crossing the Signalling VLAN is using multi-homed SCTP and an alternative SCTP path is available across another Signalling VLAN, it is not necessary to remove traffic from the VLC Route using the VLC Signalling Route. Where multi-homed SCTP is not used, or where this is the only available SCTP path, traffic shall be removed from the VLC Route using the VLC Signalling Route using the mechanisms described above. This shall be repeated for all VLC Signalling Routes using the Signalling VLAN. When this is complete the Signalling VLAN may be removed from service Graceful removal of traffic from MBF, ESCF or SBF Graceful removal of traffic from MBF, ESCF or SBF can be handled by removing traffic from all VLC Routes traversing the element in question. However, due to the volume of traffic handled by these elements, and the number of VLC Routes they may impact, the graceful traffic removal process may be prohibitively long winded, and CPs may prefer to follow a planned major works process, involving outage notifications and out-of-peak hours outages.

21 Fault Handling Management processes between VLC-Provider and VLC-User need to exist to allow the CPs to inform one another about faults impacting the VLC service, to react to the faults, minimise the fault impact and correct the underlying problem. Where the VLC-Provider has detected a fault condition affecting VLC service, the VLC-Provider should inform the VLC-User of the condition. Because the VLC-Provider is not aware of the service being provided to the VLC End User the VLC-Provider may not be reliably able to detect all fault conditions Where the VLC-User has detected a fault condition, possibly as a result of a fault being detected and raised by the VLC End User, the VLC-User should inform the VLC-Provider Fault Categorisation Faults at the VLC Service Connectivity layer can be categorised as being related to the: Individual VLC End User s Line; Signalling interface (it4a) [2]; Media transport (it4b) [2]; Signalling Control (ic1) [2]; Media stream (ib1) [2]; Configuration Faults Examples of Faults Examples of faults in each category are given below: Individual VLC End User s Line: Lack of dialtone. Inability to break dialtone. Poor voice quality. Signalling interface (it4a): Failure of signalling transport. Media stream transport (it4b): Failure of media transport. Congestion of media transport. Isolation of IP media border function. Signalling Control (ic1): Circular routeing. Unsupported media type requested. Invalid traffic/product type received (e.g emergency call received when not supported across the interconnect). Routeing errors. Media stream (ib1): Deterioration of call quality. One-way speech path. Configuration Faults: Line assigned to incorrect CP. Incorrect Dial Plan. Incorrect registration password.

22 Monitoring and reporting of Call Quality The VLC-Provider and VLC-User should track call quality within their respective networks, and (as far as possible) on calls to and from interconnected networks. End-to-end call quality may also be measured. The VLC-User can only assess the quality of calls to the point of interconnect; whereas, the VLC-Provider can measure call quality at, or close to, the AGF and hence can obtain an assessment of call quality closer to the VLC End User s actual call quality. The VLC-Provider may offer call quality measurements to the VLC-User as a feature of the VLC service. Activities which the VLC-Provider and VLC-User can undertake to track QoS levels are: automatic periodic QoS test calls across various portions of the network and across NGN interconnects; RTP signalling monitoring; QoS level recording in CDRs, maintaining a method for customers to report call quality problems. Where call quality falls below the expected quality, and particularly where National Transmission criteria are not met, the condition shall be treated as a fault and investigated, including reporting the fault to interconnect partners. 7.6 Statistical Reporting The VLC-User cannot detect some call conditions, and hence the VLC-User cannot assess these in call statistics. For example, the number of calls lost to VLC-Route congestion. For the VLC-User to record such call conditions, the statistical count will have to be sent from VLC-Provider to VLC-User. The VLC-Provider may offer its VLC-Users a statistical package, providing information on the VLC service. Such a service should only provide information to a VLC-User pertaining to the VLC-User s registered lines. 8 ACCOUNTING AND SETTLEMENT 8.1 Retail Billing VLC End User charging is the responsibility of the VLC-User network. The VLC-Provider network need not provide CDRs, so any per call charging mechanism should be built by the VLC- User network. 8.2 Wholesale Billing While individual VLC End User billing is the responsibility of the VLC-User (section 8.1), the VLC-Provider may charge the VLC-User for using the VLC service. The basis of this wholesale charge is a commercial matter between the VLC-Provider and the VLC-User. 8.3 Start of Charging SIP provides two signals which could be used to initiate the start of call charging: i) the 200 OK message to the INVITE, which is analogous to the ISUP Answer message, and ii) the Acknowledgement message to the 200 OK message, which has no equivalent in ISUP. VLC-User Networks should note the presence or absence of a 200 OK Ack on answered calls. While the absence of a 200 OK Ack is a condition which can occur, for example if the calling party clears down before the answer signal reaches the originating Call Server, persistent or high volumes of answered calls missing 200 OK Acks could indicate misuse, and VLC-User Networks should treat such conditions appropriately.