Consult 21 Interconnect Working Group

1. Consult 21 Interconnect Working Group NGN Interconnect - PSTN Emulation Technical Consultation Closure Document Allan Good – 10th March 2006 The information in this presentation relates to plans currently under development and subject to consultation, and may be subject to change. Detailed implementation depends upon a number of factors including the capabilities of suppliers and the final 21CN network design.

2. Technical Consultation Closure Document • Section 2 – shows the questions requiring CPs responses • Responses were received from 5 CPs. • Section 3 – shows the issues being addressed within the NICC • A brief note was received from the TSG/NICC forum • Section 4 – shows the related issues being addressed within the Consult21 Network Structures Group • A clarification document showing the BT view regarding Section 4 received from Tim Wright

3. Summary of Section 2 - CPs responses 1 • 2.1 Synchronisation - No sync if the MSIL uses GigE at the physical layer, not guaranteed if SDH. • 2.1.1 Will the inability to derive accurate timing from the MSIL (if the MSIL uses GigE at the physical layer) be a problem for CPs? • 5 CPs said was not an issue for them. • 2.2 Quality of Service (QoS) - IP packets QoS header not to be used by BT • 2.2.1 Does this treatment by BT of QoS marking in the header create any issues for you? • 4 CPs said not an issue for them. • 1 CP said, this does not present a difficulty while quality is managed at the VLAN layer.

4. Summary of Section 2 - CPs responses 2 • 2.3 Interconnect Locations - PoSI is point where the call enters a BT Border Gateway or equivalent. The Point of Handover is the location of the FMSAN. • 2.3.1 At which FMSAN sites co-located with Metro Nodes would you want Point of Service Interconnects? Please specify cities and towns. • 3 CPs referred to an attached list of possible connection sites. • 2 CPs needed further Commercial information • 2.3.2 At which other FMSAN sites would you be seeking NGN points of handover? Please specify cities and towns. • 2 CPs referred to an attached list of possible connection sites • 3 CPs needed further Commercial information.

5. Summary of Section 2 - CPs responses 3 • 2.4IP Addressing - Use of public IP address space • 2.4.1 Will the use of IP addresses different from internal network address be an issue for you? • 4 CPs said not an issue for them. • 1 CP requested further clarification. • 2.4.2 Would the support of publicly assigned neutral IP address space for media connections create issues for you? • 4 CPs said not an issue for them. • 1 CP requested further clarification.

6. Summary of Section 2 - CPs responses 4 • 2.5 Treatment of other Codec types – non G711 codec calls rejected • 2.5.1 Will the rejection of Codecs other than G.711 A-law be an issue for you? • 4 CPs said not an issue for them. • 1 CP agreed in principle but that ND1612 was not yet ratified. NPDS (ND1701:2006/02 Draft f) section 8.3 > G711 as a default, but that other codec types can be used and recommends that transcoding should be avoided. • 2.6 “Max forwards” parameter - Avoiding circular routing of calls • 2.6.1 Would the support of the Max forward parameter be an issue for you? • 5 CPs said not an issue for them. • 2.6.2 Would you suggest a value for Max forwards parameter other than the default value of 31? • 4 CPs said that 31 as the value for Max forwards parameter seems reasonable. • 1 CP said able to support other values. 31 is Max value in ISUP - sensible to map to SIP-I. But should be flexible and agreed bilaterally for each interconnect.

7. Summary of section 3 – Note from TSG/NICC • The TSG felt that that each of the questions were pretty clearly answered in the ND documentation so were at a loss as to why the questions were being asked but a response was agreed with the officers of NICC/TSG • 3.1 Media Layer Connectivity • 3.1.1 exchange of continuous L3 Pings to verify Media Layer IP connectivity between each side of the interconnect. • 3.1.2 if a failure of the continuous L3 pinging occurs e.g. between each end of the interconnect, notify Controlling Call Servers to stop calls from being offered to the faulty route. • 3.1.3 if a failure of the continuous L3 pinging e.g. between the Border Gateway and the NTE at one end, then notify Controlling Call Servers to stop calls being offered to the faulty route. • 3.2 “P” charging vector • The P charging vector is a globally unique call identifier. It would support capabilities for fault correlation and provision of audit trails for billing integrity and fraud detection. • 3.3 Transport protocol • The use of SCTP, TCP or UDP as a Transport protocol for SIP-I was under discussion within the NICC. Most CPs prefer to adopt the use of SCTP due to its better security aspects but others say that their suppliers could not provide SCTP in the timescale.

8. Summary of section 3 – Note from TSG/ NICC • 3.1 - IP Connectivity Failure Detection is specified in section 7.2 of ND1612 (note 1). • 3.2 – The information is currently being finalised in the ND specs. There is agreement that P-charging vector will be included in the SIP-I messages being specified in the NICC SIP-I specification (still being drafted) and the use and format of the P-Charging Vector will be specified in ND1612 (note 1). Comments have been received during the final approval of ND1612 on this subject and these will be considered at a special TSG/ARS review meeting on the 6th March 2006.  • 3.3 – Information on the signalling protocol can be found in ND1612. ND1612 (note 1) will allow all 3 protocols (i.e. SCTP, TCP and UDP) provided that a NICC specification for that protocol has been produced. The NICC SCTP specification has already been approved and published (ND1012). A first draft for a NICC TCP specification has been produced and this is now being considered. There is no NICC UDP specification.  • Note 1 - ND1612 has only recently completed its formal approval (closing date 17 February). Some comments have been received and these will be discussed and resolved at a meeting on the 6th March 2006. 

9. Summary of Section 4 – Related Issues addressed by the Network Structures Group • Extra detail has provided by BT for the Network Structures Group to help further understand the issues raised. • 4.1 Managing voice bandwidth on the interconnect link • The bandwidth on the MSIL link between Border Gateways or equivalent in each CP’s network needs to be assigned to the different services. How should this assignment be done and policed? • 4.2 Non functional aspects • The capacity of traffic passing between networks in the new technology appears to be flexible in that, up to a certain point, the interconnect can handle an amount of calls, yet to be determined. At some point, the number of calls per minute will reach a maximum and will overload arrangements will need to be employed. Also during the planning phase, interconnect resilience should be addressed. • 4.3 Impact on Call Servers • Call Servers have a finite call handling capacity which needs to be planned and policed. The impact of call volumes and call processing rates on the servers needs to be agreed for the purpose of interconnect. • 4.4 Circuit reservation for 999/112 calls • In the current legacy network circuits are reserved for the use of 999/112 emergency services. CPs who are interested in using the NGN equivalent to this reservation of capacity should note that a similar call counting or circuit reservation will need to be incorporated in their NGN design and BT interconnect for 999/112 calls.

10. End