and Quality of Service Negotiation in B3G. Systems. Zachos Boufidis ... provision, and software download management. The paper first presents an attainable ...
Exploiting the Reconfiguration Management Plane for Protocol Adaptation and Quality of Service Negotiation in B3G Systems Zachos Boufidis, Eleni Patouni, Nancy Alonistioti, Panagis Magdalinos The University of Athens, Athens, Greece {boufidis, elenip, nancy, panagis}@di.uoa.gr Didier Bourse and Karim El-Khazen Motorola Labs, Paris, France {didier.bourse, karim}@motorola.com Abstract— Reconfigurability is considered an asset of future mobile devices and associated network equipment in order to adapt the requested quality of service to volatile radio conditions while optimising the use of network resources. Such objectives can be achieved by upgrading the capabilities of mobile equipment followed by switching to the most suitable operational mode. SoftwareDefined Radio is a key enabler of terminal reconfiguration, whereas Cognitive Radio promises increased spectrum utilisation based on tools from artificial intelligence. Incorporation of additional intelligence into mobile devices and network equipment requires coordinated distribution of functionality among the user, control, and management planes. This contribution proposes smooth evolution towards reconfigurable devices and networks in the form of the so-called Reconfiguration Management Plane (RMP), which includes advanced facilities for context management, reconfiguration session control, policy provision, and software download management. The paper first presents an attainable component replacement scheme that enables online protocol adaptation. Next, the article exploits the RMP model for quality of service negotiation aiming to support software upgrades and dynamic spectrum access.
Index Terms— Component replacement, QoS negotiation, Reconfigurability, Reconfiguration Management Plane.
Introduction
C
ONVERGENCE and interworking of existing, emerging, and future radio systems and mobile networks are expected to yield a substantial portion of new revenues for incumbent operators, as well as to form a significant paragon for the emergence of newcomers. The reconfigurability concept envisages heterogeneous radios coupled with All-IP core networks, whereas integrating SDR and Cognitive Radio capabilities [1]. Over-the-air software download [2] has been an important utility for mobile operators in order to upgrade the capabilities of mobile devices online and to offer remote fault management. The vast number of radios in today’s wireless portfolio such as cellular, WiFi, WiMAX, UWB, and DVB offer the potential of dynamic network access over licensed and unlicensed spectrum, thus achieving the wellknown “always-best-connected” objective. Nevertheless, uncoordinated dynamic spectrum access and frequent user-initiated software downloads may yield critical side effects; even if networks are well-designed and strict policy rules are defined, dynamic
bandwidth demand on the wireless hop may yield temporal and spatial variations in traffic figures, thus turning parts of the core network to bottlenecks. Due to the complexity and scale of next-generation networks, legacy Quality of Service (QoS) control protocols and mechanisms in the core network (e.g., UMTS PDP signalling and Service-Based Local Policy [3]) need to be enhanced in order to support reconfiguration events. Long-term availability of multiple protocol versions and the wide range of protocol stack manifestations turn frequent protocol updates to important reconfigurability topic. Each protocol version or protocol stack instance can be installed and activated based on contextual information (e.g., location, tariff information, user needs translated to network-level operational indicators), thus necessitating generic mechanisms to achieve protocol stack and component-based protocol layer reconfiguration. This contribution exploits the Reconfiguration Management Plane (RMP) [4] in order to support seamless reconfiguration of mobile devices upon software upgrades or dynamic spectrum access. In addition, a protocol reconfiguration process is proposed for realising on-the-fly replacement of components that constitute an operating protocol [5]. The paper is organized as follows: the RMP logical model is introduced, along with its mapping to the control and management architecture for reconfigurable networks as specified in E2R project [6]. Next, the framework for reconfiguration of mobile equipment protocols is presented and hooked to the E2R architectural approach for reconfigurable devices. The contribution also proposes operations and signalling for QoS negotiation between reconfigurable devices and the network, and between interior network elements upon a reconfiguration trigger. Conclusions include deployment aspects of the RMP model as well as of the protocol reconfiguration framework.
The Reconfiguration Management Plane Overview of the RMP Functional Model End-to-end reconfiguration necessitates the proposal of collaborating management and control functions that govern the interactions between the involved entities and orchestrate the negotiation, decision-making, and enforcement of mechanisms in a dynamic fashion. The Reconfiguration Management Plane comprises a networkagnostic protocol-independent model for specifying such operations and notifications. The RMP is a logical model, i.e., an expression of an abstract view of a network element or subnet by means of functional entities incorporating specific functionality to realize physical-implementation-independent control, management, and Operations, Administration, and Maintenance (OA&M) tasks. The RMP consists of plane management modules and layer management functions that cater for reconfiguration-induced control and management tasks, such as reconfiguration services negotiation and session control, provision of reconfiguration policies, and control of software download steps. Legacy management areas are enriched in order to capture reconfigurationoriented aspects, such as profile and resource management, access and security management, and billing and accounting management. In particular, the RMP provides a coordinated set of control plane functions that address real-time terminal-initiated reconfiguration and operate on some user plane resources. In addition, management plane functions support offline networkinitiated scenarios. The RMP plane-based modelling is augmented with layer management functionality, which handles OA&M functions per layer. Fig. 1 sketches the RMP logical model. Detailed description of the RMP modules and functions can be found in [4].
Page 2 (8)
Mapping of the RMP Model to B3G Network Architecture
Mapping of the RMP Model to Mobile Equipment Architecture A challenging issue regarding the deployment of the reconfigurability concept lies in the development of a configuration system for terminals that can support operations such as monitoring and discovery of available Radio Access Technologies (RATs), selection of the appropriate RAT, and configuration and runtime modification of equipment applications, of the underlying protocol stack, and of hardware resources. Within E2R project, the RMP functionality for reconfigurable user equipment and base
Reconfiguration Management Software Download Management
ific pe c OS-s A&M O
Context Management Profile Management
Resource Management
Reconfigurability Classmarking
Policy Provision
Service Provision
Performance Management
Access & Security Management
Billing & Accounting Management
ntric k-ce wor Net OA&M
OA&M Functions
Dynamic Protocol Adaptation
s- & ines ric Bus e-cent ic Serv OA&M
RMP Layer Management
The RMP logical model can be mapped to a wide range of network configurations, depending on business and technical considerations. For example, the provision of reconfiguration services can be undertaken either by new business players or by sharing responsibilities between telecom operators, service providers, and independent actors. In addition, operator-specific planning may include network sharing scenarios or adoption of specific quality of service solutions (e.g., DiffServ versus the emerging IETF NSIS protocol suite), thus designating specific physical realisations of the RMP functionality. Fig. 2 presents a generic network architecture scenario with RMP functionality apportioned to three-tier architecture: the Reconfiguration Manager (RCM) comprises the anchor point being responsible for context retrieval and processing, provision of policy rules, overall session and negotiation control, and administration of the download process. The Composite RAN Manager (CRM) manages a composite RAN, thus catering for cooperative radio resource management and dynamic spectrum access [7]. A base station may incorporate capabilities for software download thus participating in reconfiguration sessions. Further architectural options can be found in [4].
RMP Plane Management
tric -cen RAT &M OA
cific spe iceDev OA&M
Figure 1: The Reconfiguration Management Plane. stations is offered by the equipment management and control architecture depicted in Fig. 3. The functional entities forming this architecture are the Configuration Management Modules (CMM), which are responsible for the management of the reconfiguration procedures, and the Configuration Control Modules (CCM), which are supporting entities that control and supervise the reconfiguration execution. Detailed description of the CMM and CCM entities can be found in [8].
Design Assumptions The protocol reconfiguration solution delineated in the following section bases on two design assumptions: firstly, the dynamic composition of protocol layers to form a protocol stack and secondly, the dynamic runtime modification of the protocol stack by replacing the functionality of concrete protocol layers or components within these protocols [9],[10]. Assurance of reliable operation of the protocol, i.e., with no loss of protocol data, is a requirement pertaining to both facets. In order to come up to the extra functionality introduced by the modularisation of the protocol layers, intra-layer protocol reconfiguration management functionality is introduced aiming at controlling the dynamic binding and replacement of components. The Page 3 (8)
Tier 1 Reconfiguration Control & Management
Reconfigurable User Equipment
Reconfigurable Base Station
RMP Control/Management Functions
RMP Control/ Management Functions
Tier 2 Reconfiguration Control & Management
Tier 3 Reconfiguration Control & Management ReConfiguration Manager RMP Control Functions
Composite RAN Manager
RMM RMP Control Functions
CMM_NS CMM_Dwnld
CMM_Dwnld
RMP OA&M Functions
CtxMM
SDMM
PrMM
RCMM
SPM
RSMM
RMM
Configuration Management Module
CMM_NS
RMP Management Functions
RMP Management Functions
DSAM
PPM
PeMM
CRRM
ASMM
BAMM
DSAM RUEM
DSAM CRRM CCM_PS CCM
CCM
CBCM
4G CN (Native IP) Hardware Resources
Gi
Hardware Resources
Gp
Mb Parlay GW
APC
APC
AP
AP
HSS
3G-SGSN
WiMAX AN
DVB-H AN
IMS
4G AN
MRFC
PDG/WAG
3G-GGSN
AP
Wi-Fi AN
RNC
3G-SGSN
Node B
3G AN
3G 4G AN AP APC ASMM BAMM CBCM CCM CCM_PS CMM CMM_Dwnld CMM_NS CN CRRM CSCF CtxMM DNPM DSAM DVB-H GGSN GPRS GW HSS
CSCF MRFP
3G CN Composite RAN
Third Generation Fourth Generation Access Network Access Point Access Point Controller Access and Security Management Module Billing and Accounting Management Module Component Binding Control Module Configuration Control Module CCM Protocol Stack Configuration Management Module CMM Download CMM Negotiation and Selection Core Network Common Radio Resource Management Call-Session Control Function Context Management Module Dynamic Network Planning and Management Dynamic Spectrum Access Management Digital Video Broadcast – Home Gateway GPRS Support Node General Packet Radio Service Gateway Home Subscriber Server
IMS MRFC MRFP OA&M PDG PeMM PPM PrMM RAN RAT RCM RCMM RMM RMP RNC RSMM RUEM SDMM SGSN SPM WAG Wi-Fi WiMAX WLAN
IP Multimedia Subsystem Multimedia Resource Function Controller Multimedia Resource Function Processor Operations, Administration and Maintenance Packet Data Gateway Performance Management Module Policy Provision Module Profile Management Module Radio Access Network Radio Access Technology ReConfiguration Manager Reconfigurability ClassMarking Module Reconfiguration Management Module Reconfiguration Management Plane Radio Network Controller ReSource Management Module Remote User Equipment Management Software Download Management Module Serving GPRS Support Node Service Provision Module WLAN Access Gateway Wireless Fidelity Wireless Interoperability for Microwave Access Wireless Local Area Network
Figure 2: Architecture of Reconfigurable Beyond 3G Mobile Networks. realisation of such component-based solution necessitates a new module within each protocol. The so-called Component Binding Control Module (CBCM) cooperates with the CCM Protocol Stack module (CCM_PS); the CCM_PS is responsible for composing and reconfiguring the protocol stack, whereas the CCM_CBCM a) verifies the correctness of
the forthcoming action semantically by means of protocol metadata and b) proceeds to actual realisation of dynamic component binding and replacement, while ensuring transparent switching from the old to the new component.
Page 4 (8)
CMM_IfNss CMM MD CMM Inst
CMM DMP
CMM NS CMM Dwnld
CMM Prof
CMM Sec CMM_Evnt CMM_Evnt Service API CCM_RM
CCM_PS
CCM_AP
CCM_EE
Physical Layer
Protocol Stack
Application Layer
Figure 3: Equipment Management and Control Architecture.
Protocol Reconfiguration Process Assembly of components into full-fledged protocol services is realised via intercomponent exchange of administrative information through FIFO queues. Such information includes configuration control data such as parameters of a function call. The interactions between CMM modules in the case when the RAT selection procedure dictates the downloading and replacement of a protocol component are hereafter described [5]. Firstly, the CMM Monitoring and Discovery module (CMM_MD) informs the CMM Negotiation and Selection module (CMM_NS) when it senses the new RAT. The CMM_NS negotiates with the RCM on network attachment options and in case of confirmation, delivers RAT-specific information to the CMM Decision Making and Policy enforcement module (CMM_DMP). The latter decides what protocol components need to be replaced based on profile information and policy rules. Next, it asks the CMM Download module (CMM_Dwnld) to download the selected component. The remaining steps are rather straightforward: the CMM Installation module (CMM_Inst) installs this protocol component and the CMM_DMP triggers the CCM_PS to replace the old component with the new one. At this point, the CCM_PS notifies the CBCM about the action of replacement. The CBCM retrieves the metadata for the new
component and verifies the correctness of the proposed reconfiguration action (Fig. 4). In addition, the CBCM identifies the components that comprise the specified protocol layer by processing these metadata. After the old component is paused, the CBCM performs the replacement by properly initialising the new component (using state information) and by establishing the communication links with the stationary protocol components. During the component replacement, the CBCM passes the identifier of the existing FIFO queue associated with each communication link to the new component.
Quality of Service Negotiation The authors in [11] extend the SDR Forum capability exchange steps [2] by introducing the so-called Reconfiguration Negotiation Phase for capability exchange, negotiation, and application of reconfiguration-related state information. This contribution examines the case of terminal-initiated software upgrade [12], which may pose implications on the network operation. In particular, the downloading of a new RAT may yield the initiation of radio bearers with increasing QoS demands, therefore also affecting the core network segments of the end-to-end data path. The following section proposes network actions in such scenarios. CBCM
Old Component
New Component
1: metadata retrieval for new component 2: checking composition 3: pause 4: state retrieval
5: set state 6: retrieving queue handlers 7: passing queue handlers
Figure 4: Component replacement process. Page 5 (8)
Operations and Signalling During the Reconfiguration Negotiation Phase, the terminal and the network are engaged in a loop of exchanging capability information and end-to-end state for enforcing reconfiguration strategies, as well as for guaranteeing seamless operation of user plane sessions in heterogeneous network segments (hops or domains). These facilities can be offered through installation of state information at various network elements. Fig. 5 charts the steps that comprise the Reconfiguration Negotiation Phase (a single iteration shown): 1. The RCM Reconfiguration Management Module (RCM_RMM) requests the terminal capabilities from the RCM Profile Management Module (RCM_PrMM). The latter forwards the request to the CMM; upon reception of the terminal capabilities from the CMM, the RCM_PrMM asks the RCM Reconfiguration ClassMarking Module (RCM_RCMM) to validate (and update if necessary) the Reconfigurability Classmark [13]. Finally, the current terminal capabilities are reported to the RCM_RMM. 2. The RCM_RMM determines the network nodes that reside on the data path from the terminal to a list of most frequently accessed external networks. This can be achieved by parsing a list of Access Point Name (APN) fields. 3. The RCM_RMM requests the capabilities of these network elements. This step requires communication between the RCM_PrMM and the associated network elements, which may have to be reconfigured as well in order to support potential increased demands due to terminal reconfiguration. These interior network elements are referred to as Network element Reconfiguration Support Functions (N-RSFs) in Fig. 5. 4. The RCM_RMM asks the RCM Policy Provision Module (RCM_PPM) to generate the hereafter called End-to-end Reconfiguration Label (ERL) [4] and to apply ERL-related state to transit nodes.
CMM
RCM RMM
N_RSF
RCM PrMM
RCM PPM
RCM RCMM
1a. terminalCapabilitiesRequest 1b. terminalCapabilitiesRequest 1c. terminalCapabilitiesResponse 1d. Validate ReconfigurabilityClassmark 1e. terminalCapabilitiesResponse 2. Discover N-RSFs 3a. networkCapabilitiesRequest 3b. networkCapabilitiesRequest 3c. networkCapabilitiesResponse 3d. networkCapabilitiesResponse 4a. applyERLstate 4b. Generate ERL 4c. applyERLstateCommand 4d. Interior network negotiation 4e. applyERLstateAck 4f. applyERLstateComplete (ERL)
5a. Determine RINs 5b. Negotiate and apply RIN Operation 6a. notifyNetworkCapabilities 6b. notifyNetworkCapabilities (ERL, RIN Operation Scheme) 6c. notifyNetworkCapabilitiesAccept 6d. notifyNetworkCapabilitiesAccept
Figure 5: Negotiation signalling. The ERL comprises an expression of the impact of terminal reconfiguration on perceived end-to-end QoS. Such label is installed on all network elements on the data path for assisting in the admission test, resource reservation, and packet classification procedures. Examples of parameters encapsulated in the ERL include the MS class, the IMEI Software Version (IMEISV), the Network Mode of Operation (NMO), the RAN mode, the RAT type, the MS classmark, the CN classmark, the Radio access classmark, the Network Identity and Time Zone (NITZ) - as well as yet-to-be-proposed identifiers for Beyond 3G networks, including the Reconfigurability Classmark. Application of ERL state information may result in intra-element Page 6 (8)
decisions as well as in negotiations with neighbour network elements for the modification of resource-specific parameters (e.g., upgrade of supported bearers and optimal setting of bearer parameters). Finally, the N-RSFs inform the RCM_PPM about the outcome of installing ERL state. 5. Based on these notifications, the RCM_RMM classifies the network elements to three categories [4]: Reconfiguration-Enabled Nodes can support reconfiguration-induced signalling and operations; Aware Reconfiguration Ignorant Nodes (RINs) are aware whether they can support such signalling and adaptation of supported resources; finally, Unaware RINs have no capabilities to interpret any reconfiguration signalling. Thus, user traffic in such nodes is not protected by abnormal download situations. The RCM_RMM and the N-RSFs negotiate the necessary actions for efficient operation over these classes of nodes, depending on the framework for operation over RINs. 6. Finally, the RCM_RMM informs the CMM (via the RCM_PrMM) of the network capabilities so as to proceed to subsequent download steps according to [2].
Building on the Reconfiguration Management Plane model, a novel negotiation control scheme for quality of service assurance was proposed, aiming at proactively supporting instantaneous traffic variations due to software upgrades and uncooperative dynamic spectrum access. The proposed procedures can be implemented via SIP/SDP and COPS protocol extensions on top of legacy UMTS PDP procedures. In addition, the QoS NSLP feature of in-call bandwidth modification can be exploited for reservations that are not necessarily end-to-end [14]. Deployment of overall RMP functionality can be a gradual process while SDR and Cognitive Radio equipment is installed, with no impact on the operation of already deployed 3G systems. For example, the described procedures can be seamlessly supported in Iu mode, in the same overlay fashion CAMEL procedures are optionally triggered during, e.g., location management procedures. ACKNOWLEDGEMENT This work has been performed in framework of the EU funded project E²R. authors would like to acknowledge contributions of their colleagues from consortium.
the The the E²R
REFERENCES
Conclusion This contribution proposed a protocol reconfiguration scheme based on component-based design. The replacement of components within a protocol layer affects neither the functionality of the protocol nor the communication with its correspondent peers. In addition, during the reconfiguration process, operation of the other constituent components is unaffected. The queue-based component replacement scheme overcomes the limitations posed by rival solutions such as the FRACTAL framework [10], which adopts a time-consuming recursive model with sub-component sharing and requires both suspension of all external communication channels and empty status at replacement time.
[1]
[2]
[3] [4]
[5]
[6]
S. Haykin, “Cognitive radio: Brain-empowered wireless communications”, IEEE Journal on Selected Areas in Communications, Vol. 23, No. 2, Feb. 2005. SDRF-02-A-0007, “Requirements for Radio Software Download for RF Reconfiguration”, SDR Forum Approved document, Nov. 2002. 3GPP TS 23.207: "End-to-end Quality of Service (QoS) concept and architecture". Z. Boufidis, N. Alonistioti, and M. Dillinger, “Network Control and Management for Beyond 3G End-toEnd Reconfiguration”, 14th IST Mobile and Wireless Communications Summit, Dresden, Germany, June 2005. E. Patouni, N. Alonistioti, and P. Magdalinos, “A Framework for Protocol Reconfiguration”, in the Proceedings of the Seventh IFIP International Conference on Mobile and Wireless Communication Networks, Marrakech, Morocco, Sept. 2005. IST-2003-507995 Project E²R (End-to-End Reconfigurability),
http://www.e2r.motlabs.com/ Page 7 (8)
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
C. Kloeck et al., “Functional Architecture of Reconfigurable Systems“, 14th WWRF Meeting, San Diego, California, USA, July 2005. J. Vogler et al., “Equipment Management and Control Architecture”, IST-2003-507995 Project E²R White Paper, July 2005. G. Minden et al., “Composite Protocols for Innovative Active Services”, DARPA Active Networks Conference and Exposition (DANCE'02), San Francisco, CA, USA, May 2002. E. Bruneton, T. Coupaye, and J. B. Stefani, “Recursive and Dynamic Software Composition with Sharing”, 7h International Workshop on Component-Oriented Programming (WCOP02), Malaga, Spain, June 2002. Z. Boufidis, N. Alonistioti, and E. Mohyeldin, “Generic Process for Terminal Reconfiguration through Software Download”, SDR Forum Input document SDRF-04-I-0081, SDR Forum 41st Meeting, Phoenix, Arizona, USA, Nov. 2004. 3GPP TS 32.600: “Telecommunication management; Configuration Management (CM); Concept and high-level requirements”. F. Berzosa et al., “Classmarks for Reconfigurable Terminals”, WWRF 14th Meeting, San Diego, California, USA, July 2005. Internet-Draft: "NSLP for Quality-of-Service signalling”, Next Steps in Signalling working group, draft-ietf-nsis-qos-nslp-08.txt, Oct. 2005 (work in progress).
Page 8 (8)
