Formalising the Next Generation Network End-User QoS Signalling and Control Framework

Transcription

1 Formalising the Next Generation Network End-User QoS Signalling and Control Framework Derrick Mwansa and Hu Hanrahan Centre for Telecommunications Access and Services 1 School of Electrical and Engineering University of the Witwatersrand, Johannesburg Private Bag 3, WITS 2050, Republic of South Africa Tel: Fax: {d.mwansa, h.hanrahan}@ee.wits.ac.za Abstract The next generation network end-user QoS signalling and control framework needs formalisation. Drawing and building on the foundation work of standard bodies and organisations such as the ETSI, MSF and ITU-T, this paper formalises such a framework. The paper also provides reference guide to developing an end-to-end end-user QoS signalling information model. Index Terms end-user QoS, signalling and control framework, information flows and flow elements. I. INTRODUCTION nd-user Quality of Service (QoS) signalling is signalling of Eservice quality affecting information between QoS functional entities. QoS signalling and control is necessary to ensure that the various levels of QoS as requested by the endusers are met. A model of a QoS framework for managing enduser services in the Next Generation Network (NGN) is presented in [1]. The model is biased to developing an integrated SLA-driven QoS framework that also strives to harmonise the business concerns of future service trading models and the performance management aspects of the NGN into a common model. Modelling inputs are realistic QoS viewpoints of the end-user, service provider and NGN roles taken at a point far into the future. This paper formalises a framework, within the framework presented in [1], for NGN end-user QoS signalling and control, omitting business QoS functions. Currently end-user QoS signalling and control solutions for the NGN are still very much in premature stages. The paper draws and builds on the foundation work of standard bodies and organisations such as the ETSI, Multiservice Switching Forum (MSF) and the ITU-T. The organisation of this paper follows a conventional metasystem design and development methodology. Section II outlines the procedures of QoS operation in the QoS lifecycle. Section III presents the end-to-end QoS signalling and control framework architecture. Section IV abstracts the signalling 1 The Centre is supported by Telkom SA Limited, Siemens Telecommunications, Sun Microsystems SA and the THRIP Programme of the Department of Trade and Industry information flows and flow element model. Section V closes the paper and identifies future work. II. END-US QOS PROCEDURES AND LIFECYCLE QoS should be provided on a per user, per service or application basis to all NGN end-users, as in clause 4.2 of [2]. In [3], five QoS lifecycle phases are identified, and these are the inform, negotiate, establish, operate and release phases. In general there are many possible ways in which the enduser may inform or request for QoS to the Service Provider (SP). The end-user may request for QoS by subscription via third party agents such as the business functional entities in [1]. The end-user may also subscribe for QoS directly to the serving SP, for example, during an access session as in TINA [4]. QoS requests may also be made explicitly by the end-user on a call-by-call basis at call setup time and during the operational (service usage) phase. The former requires no QoS signalling between the end-user and the SP at call setup time. However, generally, a QoS request should be met whether it has been made via subscription or on the fly. Providers have QoS offers (offered QoS) tied to specific offered services. The provider s offered QoS is determined by a number of factors such as the available resources and QoS policy. Providers may not always meet the required QoS of end-users. In the negotiation phase, the QoS required by the end-user and provider s QoS offers, are used to determine the best possible QoS for the end-user. The end-user is notified of whether the QoS requested is in fact honoured or not. If the QoS is not honoured, alternate QoS offers together with causes for the failure must be presented to the end-user. The end-user makes the final decision as to whether the call should proceed with the suggested QoS or not. In any case, the QoS negotiation phase yields agreed QoS which is used in establishing the particular call or starting a service session. The establishment of the call or session requires allocation of resources in the NGN to deliver the service with agreed QoS. During service invocation or operation phase, resources are reserved and committed per agreed QoS. When the call or session is finally over, resources must be released. Other causes for release of resources may also arise during the time

2 Originating Providers QoS Policy Function QPF Service Agents r2 SA1 Terminating providers SA2 r3 Transit Providers r6 SP QoS Coordination Functions SQCF1 r4 SQCF2 r5 SQCF3 r1 r8 r9 r10 r7 NP QoS Coordination Functions NQCF1 r11 NQCF2 r12 NQCF3 r13 r14 r14 Originating User CPE Router CR CR CR Terminating User Media Flows Edge Router Core Router Fig. 1. Architecture of a QoS Signalling and Control Framework. Broken lines depict interfaces for QoS signalling. Solid thick lines represent media flows. the call is in progress in the operational phase. III. QOS SIGNALLING AND CONTROL ARCHITECTURE A layout is shown, in figure 1, of how QoS signalling and control functions may be arranged for end-to-end QoS signalling in a two-party call scenario across the three roles that providers may play (originating, transit, and terminating). Providers may also be visited or home service providers. Signalling interfaces and media flows are also shown. For the sake of establishing the end-to-end QoS signalling and control concept, it is assumed in figure 1 that the end-user terminals connect to the customer premises equipment router or directly to the edge router. The framework is an amalgamated mapping of frameworks in [1], [2] and [5]. The objective of the architecture in figure 1 is to have a generic functional entity model adaptable to technology specific implementations. A. Description of functional entities The entities shown in figure 1 are defined as follows (most of these definitions may also be found in [2]): 1) Calling User: is an application at the calling user's terminal that instigates the service request. It acts on behalf of the human user to request the establishment of an end-to-end call. 2) Calling User s Service Agent (SA1): processes the calling user's request for end-to-end QoS signalling. It determines whether current policy permits the requested QoS to be used. It then initiates a call towards the destination address or rejects the call request back to the calling user. 3) QoS Policy Function (QPF): consults its service database to determine whether the calling user is permitted to make a call with the requested end-to-end QoS to the indicated called user. 4) Originating SP QoS Coordination Function (SQCF1): negotiates and establishes a particular QoS on behalf of the calling user. It requests the provision of a bearer capable of supporting the desired end-to-end QoS and passes on the call request towards SQCF3. Originating and terminating points must have already been determined. 5) Transit SP QoS Coordination Function (SQCF2): an intervening SP QoS coordination function that establishes a particular QoS on behalf of the originating SQCF. Functionality is similar to SQCF1. i.e. it requests provision of a bearer capable of supporting the desired end-to-end QoS and passes on the call request towards the terminating SQCF. 6) Terminating SP QoS Coordination Function (SQCF3): establishes a particular QoS on behalf of the called user. Again, functionality of SQCF3 is similar to SQCF1. i.e. requesting the provision of a bearer capable of supporting the desired end-to-end QoS and passing on the call, this time, towards the terminating service agent. 7) Terminating Service Agent (SA2): processes an incoming call to the called user. It informs the called user about the QoS required with an incoming call. The transit service provider does not need to host a service agent unless it is a serving SP (having end-users attached to it). 8) Terminating User: is the application at the called user s terminal at which the service request is terminated. It acts on behalf of the human user to accept the establishment of an endto-end call with a specified QoS. 9) Originating NP QoS Coordination Function (NQCF1): the transport QoS coordination function of the Network Provider (NP) serving the originating user. It attempts to establish a bearer connection between the indicated incoming user access point and an appropriate outgoing network access point capable of providing the requested end-to-end QoS. It is responsible for setting up and tearing down of bandwidth within the network and for controlling access of individual calls to this bandwidth [5]. It installs appropriate policy in edge routers to police the flows per call basis. It has responsibility for the aggregate bearers that it has created and is the arbiter as to whether a call may have access to the reserved bandwidth. The NQCF decouples the call control functions from the underlying network specific bearer

3 information and allows for generic network QoS signalling between the SP and NP interface to be realised. This is in conformance with the vision of the NGN [6] where a generic network control layer is envisioned regardless of the underlying network in question. The ITU-T [9] needs to include this concept into their architectures and s model. 10) Transit NP QoS Coordination Function (NQCF2): an intervening network provider QoS coordination function. It attempts to establish a bearer connection between the indicated incoming network access point and an appropriate outgoing network access point capable of providing the requested endto-end QoS. It is similar to NQCF1 in other functionality. 11) Terminating NP QoS Coordination Function (NQCF2): the transport QoS coordination function of the network provider serving the terminating or called user. It attempts to establish a bearer connection between the indicated incoming network access point and an appropriate outgoing user access point capable of providing the requested end-to-end QoS. It is similar to NQCF1 in other functionality. 12) Edge Router: provides boundary functions for traffic marking based on classes. It applies appropriate policy to individual media flows under the direction of the NQCF. It contains security functions to ensure that only authorised flows are allowed access to the network resources [5]. 13) Core Router: responsible for passing traffic through the network in large volumes (preferable aggregated volumes) whilst providing differential treatment. B. Interfaces It is important to consider each of the interfaces defined in figure 1, to understand the primitives that flow over the interfaces and possibly try and identify or enhance candidate s or architectures for the same [5] (enhancement of s and architectural frameworks for end-to-end QoS is regarded as future work in this paper). In figure 1, interfaces or relationships r1 through r10 are self-explanatory. Relationships r11 through r14 need to be clarified. Relationships r11 and r12 are inter-network federation interfaces. They are necessary when two or more NPs need to federate on their own without the control of an SP. For example, it is not always the case that a transit NQCF receives QoS signalling from the transit service provider QoS coordination function. In this case network providers need to federate on their own and provide their own QoS signalling. Relationship r13 between the NQCF and the edge or boundary routers is provided to allow the NQCF to control the underlying edge routers on a call-by-call basis. Relationship r14 between the NQCF and the underlying network elements is provided to allow the NQCF to setup and tear down aggregate bandwidth reservations across the network. The aggregate traffic extends from the edge via the core to the edge. In as far as end-to-end QoS signalling is concerned and in figure 1, only interfaces or relationships r1, r4, r5, r7, r8, r9, r10, r11 and r12 need to be exposed, well established and adhered to. Relationships r2, r3 and r6, for example, are internal to the respective SPs participating in the end-to-end service delivery. Similarly relationships r13 and r14 are internal to the particular NPs providing the transport service. Providers internal interfaces may have their implementations that could be very technology dependent. In addition there are many issues surrounding what could be signalled across the transport network federation interfaces (relationships r11 and r12) since information flows at relationships r4 and r5 could very much be made to carry all of the information required for horizontal end-to-end QoS signalling. Therefore, due to the foregoing analysis and in as far as end-to-end end-user QoS signalling is concerned, information flows at relationships r2, r3, r6, and r11 through r14 are not tackled in this paper. C. Concepts in the QoS Signalling framework End-to-end QoS signalling is used here as a concept of signalling quality affecting information between QoS functional entities some of which may be service components. Service signalling is used here as a concept of signalling service affecting information between service components for the purpose of delivering the requested service. QoS signalling in the architecture of figure 1 is imbedded within call or session signalling. This means that traditionally QoS-less service signalling architectures and frameworks need to be made QoS-aware service signalling mechanisms by enhancing them with methods for QoS support. End-to-end end-user QoS negotiation takes place at call control level. In the framework there is no direct contractual agreement on matters of QoS between the end-user and the transport network provider. The end-user relates to the transport provider through the SP. More formally, access to the transport network is via the SP QoS coordination functions (call control functions) which instruct the NP QoS Coordination Function (NQCF) to permit individual (per call) flows from the edge router. Traffic not authorised this way must not be granted resources by the edge router [5]. Signalling possibilities: There can be many ways of signalling QoS. For example passing individual QoS parameters across interfaces, or passing standardised QoS classes as opposed to individual parameters, or both. The first case would be characterised by heavy signalling load, and precision-point QoS monitoring and control procedures. The second case, QoS class-based signalling, reduces signalling load and can be achieved by passing QoS range representative values (class identifiers) as opposed to passing detailed QoS parameters across interfaces. QoS monitoring and control procedures in the second case are based on QoS ranges and not precisionbased. This is a most desirable way of signalling but it requires standardisation of QoS classes (parameter ranges). While standardisation of QoS classes can be achieved, it cannot happen at the user-sp interface; users always tend to be relaxed when making choices about quality. They want userfriendly QoS categories or flavour names such as gold or best quality. Therefore SPs need to have flexibility of introducing QoS flavours in whatever form or language the end-user wants but they have the onus of mapping them into standard QoS

4 classes for onward transmission to other SPs and NPs. Standardised QoS classes will play a major role in end-to-end QoS signalling and control. QoS Contexts: In the QoS framework, there normally exist a high-level description of the service that the user wants to consume, accompanied by a high-level user friendly QoS specification of the desired service quality level which may be in categories such as the Olympic gold, silver or bronze. If the user wishes to have a detailed presentation of QoS parameters these should be passed on as required. In general the high-level end-user QoS specifications need to be mapped into application level QoS. At the application level both the service and QoS description are more detailed and can be stated in terms of the media that constitutes the service, for example voice, data and video. The QoS specification at the application level can also be in terms of encoding (e.g. G.711, GSM Full Rate, MPEG4, etc) and middleware or application transport (e.g. RTP). The application level QoS needs to be mapped into generic transport service QoS requirements independent of the underlying network technology. The generic transport network QoS requirements are then mapped into network specific transfer capabilities (e.g. Y.1541 for IP, I.356 for ATM; X.146 for FR). To achieve the QoS as requested by the end-user, the various QoS contexts at all levels in the NGN hierarchy and across participating domains must be well co-ordinated end-toend. A hierarchy of QoS Contexts is illustrated in figure 2. High-level user service description and perceived QoS requirements Application level service description and QoS specifications (Media, Encoding, Middleware) Generic transport service QoS requirements Network specific transfer capabilities Fig. 2. Hierarchy of QoS Contexts QoS Provisioning & control functions IV. SIGNALLING INFORMATION FLOWS AND FLOW ELEMENTS The challenge of setting up an information flow model for end-to-end QoS signalling lies in the task having to drive a generic information structure. The generic information structure needs to be aware of the various QoS contexts at different levels of the NGN hierarchy, domain demarcations, service and network providers QoS policy, various end-user QoS preferences, service types, and multiple technologies used to deliver the services end-to-end. The generic information elements form a common information model for all cases with variations only of the actual values of the information elements. These measures then form the basis of end-to-end QoS negotiation, provisioning and control. TIPHON [2] offers a comprehensive set of information flows for signalling and control of end-to-end QoS which can be adapted to most existing and emerging service architectures and signalling and control frameworks. TIPHON QoS information model, however, primarily assumes voice telephony over TIPHON compliant systems. The TIPHON information model needs extension to generic multimedia service QoS signalling and control mechanisms as opposed to voice only. The application of the TIPHON QoS information flow model together with the enhancements is given in the following subsections: 1) Relationship r1 (OrigQoSEstab): between the calling user application and the calling user s service agent, is primarily used for call setup signalling. It is a confirmed information flow that is sent from the calling user to the originating service agent (SA1) to represent a request for a new call establishment with a specified end-to-end QoS. Table 1 lists the elements within the OrigQoSEstab information flow. 2) Relationships r4 and r5 (QoSEstab): is a confirmed information flow that is sent across relationships r4 and r5 to indicate a request for the provision of a guaranteed end-to-end QoS for the associated call. It is provided to enable peer-topeer call control communication with QoS. Table 2 lists the elements within the QoSEstab information flow. 3) Relationship r7 (DestQoSEstab): is a confirmed information flow that is sent across relationships r7 from the terminating service agent (SA2) to the called user application to indicate request for a new call establishment with a specified end-toend QoS. Table 3 lists the elements within the DestQoSEstab information flow. 4) Relationships r8, r9 and r10: as in [5], transport resources are allocated by a two-stage process, reserve and commit. i.e. resources are reserved as part of the initial call setup but committed at the point where a bearer is established. Therefore three flow types are identified between the call control functions (SP QoS coordination functions) and the NP QoS coordination functions. These are TRMReserve, TRMConnect, and TRMRelease. TRMReserve: is a confirmed information flow that is sent across relationships r8, r9 and r10 to request the reservation of a media transport path with a specified end-to-end QoS towards the called user s address. Table 4 lists the elements within the TRMReserve information flow. TRMConnect: is a confirmed information flow that is sent across relationships r8, r9 and r10 to request the establishment of a previously reserved media transport path with a specified end-to-end QoS towards the called user s address. Table 5 lists the elements within the TRMConnect information flow. TRMRelease: is an unconfirmed information flow that is sent across relationships r8, r9 and r10 to request that a previously reserved media transport path is released, as it is no longer required. Table 6 lists the elements within the TRMRelease information flow. In the tables, italised text in brackets indicates that only one item is included at a time in the information element.

5 Table 1: OrigQoSEstab Value Req Resp Comments Calling user ID Originating username O - Username is optional (symbol O) here because the SP usually knows the originating enduser before a service session begins, as in TINA [4]. However non-tina session models may not assume an access session to have taken place, in which case the calling username should be signalled to the service agent. Not in scope of TIPHON R4. Username may be transport address or stream flow end-point as in TINA. Called user ID Destination username M - Mandatory (symbol M). Corresponding value in TIPHON is TIPHON username. Username may be transport address or stream flow end-point as in TINA. Service name Service name M - Name of service that the end-user and subscribing SP know the service by. Can be voice, video on demand, etc. TIPHON assumes a voice service only. Not in scope of TIPHON R4. Service QoS flavour ID Application Bearer service Codec type and packetisation Application data transport Transport network QoS flavour M M High-level service QoS category or flavour that the SP specifies to the end-users. The subscribing SP has task of translating the service QoS flavour into a standard application QoS class and generic transport service QoS (bearer service QoS) for onward transmission to other SPs and NPs, respectively. Service QoS flavours could be gold, silver, bronze, etc. or TIPHON QoS categories, e.g. best effort, acceptable, medium, high and best. Application QoS class O O For advanced users, e.g. 1, 2A, 2M, 2H and 3 if TIPHON categories were used. Optional at relationship r1 because users prefer user-friendly categories or flavours. Not in scope of TIPHON R4. Bearer QoS class O O For advanced end-users. Generic transport network service QoS class identifier. A representative value or ID of the transport network QoS parameters. The service provider domain translates high-level service and application QoS classes into bearer service QoS classes. Therefore this information element is optional at relationship r1. List of possible codecs (codec type; frames per packet) M O List of possible codecs at end-user terminal. In response message only the proposed codec is presented. The list of codecs is limited to a single entry in the response. Optional because this information element is only presented when field is set to end-to-end QoS established [2]. Application O - Optional. Application data transport for end-user. Default may be RTP as in [7]. Also called middleware as in Rajahalme [8]. Network O - Supporting transport network at end-user terminal. May be TCP/IP, UDP/IP, ATM, ISDN. Default may be set to UDP/IP, if voice, as in [7]. (a) End-to-end QoS established; (b) Rejected (requested QoS not available; called user unknown; no compatible codec available; policy rejection) - M Either end-to-end QoS may be established or rejected. When rejected the rejection cause must be included in the information field. An alternate QoS flavour or category may be presented at the same time as well. This is shown in the Service QoS flavour which itself is shown as mandatory. Mandatory because whether or not the QoS has been honoured it should be reported to the end-user. Application QoS class and Bearer QoS class fields are optional ways of QoS signalling at relationship r1. Table 2: QoSEstab Value Req Resp Comments Calling user ID Originating username M - Calling username is mandatory here because it must be passed on to the next peer SP QoS coordination function. Corresponding value in TIPHON is TIPHON username. Username may be transport address or stream flow end-point as in TINA. Called user ID Destination username M - Similarly called user ID is mandatory. Corresponding value in TIPHON is TIPHON username. Username may be transport address or stream flow end-point as in TINA. Application Codec type and packetisation Bearer service Traffic descriptor Destination service domain Application QoS class M - Application QoS classes are a preferred signalling mechanism for relationships r4 and r5, as opposed to transport parameters. This is done in order to reduce signalling load and precision point QoS monitoring and control. Not in TIPHON R4. List of possible codecs (codec type; frames per packet) M O Codec at end-user terminal as in OrigQoSEstab information flow. The list of codecs in response is limited to a single entry. The information element is included if the result of the request is Requested QoS available. Bearer QoS class O - Optional because application QoS classes are a preferred signalling mechanism for peer-topeer call control. Useful if the SP needs to signal transport service QoS classes to a next NP, for example if the originating NP and transit NP cannot federate. Bearer QoS classes are preferred to signalling individual network parameters. Bearer are representative values of generic transport network parameters such as maximum delay, maximum packet delay variation, maximum mean packet loss. e.t.c. Not in TIPHON R4. Media peak rate, max. M - Characterises the resource requirements of an application data flow. Mandatory. QoS levels media frame size to be granted only when flow remains conformant to its traffic descriptor. Network specific O - Optional. As in TIPHON [2]. address (a) Requested QoS available; (b) Rejected (comments) - M Either case (a) or case (b). Rejection causes for case (b) are: Requested QoS not available; Called user unknown; No compatible codec available (i.e. All rejection causes as in OrigQoSEstab except policy rejection).

6 Table 3: DestQoSEstab Value Req Resp Calling user ID Originating username M - Service QoS QoS flavour M M flavour ID Application Application QoS class O O QoS Class ID Bearer service Bearer QoS class O O Codec type and List of possible codecs (codec M O * packetisation type; frames per packet) Application Application - O data transport Transport Network - O network - Indicated codec selected - Rejection (cause: codecs not supported) - M * The list of codecs is limited to a single entry in the response just as in QrigQoSEstab. This information element is included if the result of the request is indicated codec selected. Table 4: TRMReserve Value Req Resp Traffic Alphanumeric handle M - identifier Bearer service Bearer QoS class M M Transport QoS parameters Maximum delay, maximum delay variation, maximum mean packet loss O O * Transport parameters qualifier Traffic descriptor Source transport domain Destination transport domain (a) Transport QoS parameters indicate total remaining budget (b) Transport QoS parameters indicate budget available per domain O - Media peak rate, maximum M - media frame size Network specific address M - Network specific address M - - Requested resource reserved - Rejection (cause: Requested resources not available; Destination unknown) - M * This information element is included if the value of the transport parameters qualifier in the request is Transport QoS parameters indicate total remaining budget. In any case the transport QoS parameters field is optional because bearer service QoS class is the preferred signalling mechanism here. If bearer service QoS class-based signalling is followed, transport QoS parameters and transport parameters qualifier need not be signalled. In this case also transport networks need to federate and determine the QoS budgets across domain on their own based on the requested bearer QoS class signalled by the SP to the serving NP. V. CONCLUSIONS AND FUTURE RESEARCH Building on the foundation work of competing standard bodies and organisations, we have formalised a framework for end-to-end end-user QoS signalling and control for the next generation network. The formalisation concentrated on Table 5: TRMConnect (as in TIPHON [2]) Value Req Resp Traffic Alphanumeric handle M - identifier - Reserved connection completed - Rejection (cause: unable to complete connection) - M Table 6: TRMRelease (as in TIPHON [2]) Value Req Traffic identifier Alphanumeric handle M procedures of QoS operation, architecture of the QoS signalling and control framework, concepts in signalling, and information flows and flow elements. Future work focuses on an information structure and mapping of the general abstracted information model into technology specific implementations of service and network provider architectures, and midterm signalling solutions such as Parlay, TINA and SIP, respectively. VI. REFENCES [1] D. Mwansa and H.E. Hanrahan, Conceptual QoS Framework for Managing End-User Services in the Next Generation Network, in Southern African Telecommunication Networks and Applications Conference, September 2003, ISBN [2] ETSI, TS v4.1.1: Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; End-to-End Quality of Service in TIPHON Systems; Part 3: Signalling and Control of End-to-End Quality of Service. Cedex, France: European Telecommunications Standards Institute, January [3] A. Halteren, A concept space for modelling QoS aspects. arch.cs.utwente.nl/presentations/qtime-23jan2002.pdf, January Last accessed 14 August [4] TINA-C, Service Architecture version 5.0. Telecommunications Networking Architecture Consortium, June [5] G. Gallon, Quality of Service for Next Generation Voice Over IP Networks, Multiservice Switching Forum, February [6] H. Hanrahan and D. Mwansa, A vision for the target next generation network, in Southern African Telecommunication Networks and Applications Conference (SATNAC), September [7] ITU-T Study Group 13, NP : Proposed joint activity on generic control mechanism for end-to-end QoS service control and signalling development based on IP transfer capabilities and IP QoS classes, Cheju - Korea, March [8] J. Rajahalme, et al., Quality of service negotiation in TINA, in Global Convergence of Telecommunications and Distributed Object Computing, pp , IEEE, November ISBN X. [9] A. Le Roux, Brain storming on NGN: Future Directions for Control Protocols, ITU-T SG11, November T/worksem/ngn/SG11-info-002.ppt, last accessed 22 April Biography: Derrick Mwansa is a postgraduate student at Wits University. He is a member of the Centre for Telecommunications Access and services. Hu Hanrahan is Professor of Communications Engineering at Wits University. He leads the Centre for Telecommunications Access and Services (CeTAS), a research and advanced teaching centre devoted to improving knowledge and practice in the evolving telecoms access networks and telecoms services.