当前位置:首页 >> >>

Profile System for Management of Mobility Context Information for Access Network Selection

Profile System for Management of Mobility Context Information for Access Network Selection and Transport Service Provision in 4G Networks
Ivan Armuelles Voinov1, Jorge E. López de Vergara2, Tomás Robles Valladares1, David Fernández Cambronero1

Dept. of Telematic Systems Engineering Technical University of Madrid (UPM) Madrid, Spain {ivan | robles | david }@dit.upm.es

Departmento de Ingeniería Informática Universidad Autónoma de Madrid (UAM) Madrid, Spain jorge.lopez_vergara@uam.es


Abstract. High level services and data transport service provision are facing important advancements towards a more flexible business models and Internet services with the internetworking of several complementary access technologies using IP. This imposes new requirement in users’ mobile terminal, such as intelligent discovery and selection of access networks, vertical handover support and roaming. The result of such integration of networks, also known as “4th Generation Networks”, will require that transport network and user’s terminal coordinates for providing of a “persistent” transport service. This paper presents the conceptual high level description of a context-based management distributed service and profiling system based in OWL, the W3C ontology language, in order to provide this persistent transport for mobile user’s data in a heterogeneous environment of IP-based network.



Lately, mobile communications are facing important advancements towards a more flexible business model and fresh Internet-like services, with the introduction of new 2.5G/3G of mobile communication systems. Additionally, several complementary access technologies are evolving, for instance, broadband WLAN and broadcast systems are becoming available; systems like Bluetooth are being developed for ad hoc and short-range connectivity. The interconnection of all these access networks (ANs) using the Internet Protocol (IP) has been envisioned as the mean by which the user will be in some sense “always best connected”. The results of such evolution, also known as “4th Generation Networks”, are related to more flexible service provision characterized by dynamic user registration, flexible charging/accounting models; advanced profile management of users, networks and terminals; context aware systems and others [1].
This work has been partially developed during the MIND and ANWIRE IST projects cofunded by the European Community

This envisioned future imposes basic requirements in mobile user’s terminal such as cross-layer and TCP/IP-based design; QoS, multi-homing and mobility support; adaptation and re-configuration at different level of the protocol stack, intelligent discovery and access network selection, ad hoc connectivity and roaming to other different networks [2]. In this paper we present the conceptual high level description of a context-based management distributed service and profiling system in order to provide a persistent transport for mobile user’s applications in a heterogeneous environment of IP-based network. The paper is organized as following: section 2 describes the model and concepts introduced for defining a persistent transport service in 4G scenarios; section 3 presents our perspective of the use of mobility context information management system in 4G networks and an ontology-based solution; section 4 provides the high level description of the management system; section 5 discuss different alternatives for the deployment of a mobility context management service for persistent transport provision in future scenarios; section 6 summarizes the conclusions.


Concepts for 4G Networks description

In future 4G networks, it will be possible to get access to services and to use distributed applications independently of the time and the user location. When moving, a user will access different wireless services via his/her Mobile Terminal (MT). We define “wireless services” (WSs) as a set of functions and facilities related to applications and communications infraestructures offered to consumers by providers, and providing consumers with requested resources according to a service agreement. WSs will be provided by a wide range of players which will offer their functions to other players or users. In order to avoid complex classification of these players, we differentiate them by the main facilities that they offer. These belong to the class of “infrastructure service provider” which serves data transportation (e.g., access network service and proxy service providers) or to the class of “application service provider” that correspond to upper layers. A mobile user will access to wireless services depending on its activities and preferences and its MT capabilities. In order to make an abstraction of the relationship between the mobile user and its MT when accessing to WSs, we introduce the concept of “Mobile Customer” (MC). A MC is a specific terminal configuration and application settings according to the current user’s role and features of the selected access network. During the day, the user will develop “roles”, i.e., different activities and relationships with other individuals; in each role, the user might react differently. The user’s roles are represented by its respective “profiles” of WSs usage.


Thoughts on Context-aware Services Context and Profiles

In future heterogeneous environments of Wireless and Mobile Networks it will be possible to find situations where the MT shall be able to take its own decisions related to its adaptation and configuration [3]. The MT should be aware of the user activities patterns. These patterns are governed by user‘s roles which state his/her preferences when developing different activities. Such preferences and user context information are usually declared in a profile. 3.1 Context management for Persistent Transport Service Provision

The management of the knowledge of user context aspects such as the user identity, its activity and the respective location and time is one of the main issues of “Contextaware Systems”. A system is context-aware if it uses context to provide relevant information and/or service to the user. Context is defined as “any information that can be used to characterize the situation of an entity” [4]; an entity could be any element like a person, place or object. The use of context-aware system has been traditionally focused to the adaptation of services and applications according to its location, the collection of nearby people and objects, as well as changes of the objects over time. In the area of mobile communication services, the Open Mobile Alliance (OMA) and 3GPP had defined architectures for network services and content adaptations in the Application and Content Providers taking in consideration the capabilities of the terminal device and the user preferences [5][6]. More recently, the exchange of context information has been proposed for the proactive configuration of IP-based access network elements in order to improve the handover process of the MT. In the IETF, the Seamoby WG had proposed a Context Transfer Protocol that exchange context information such as security context, policy, QoS, header compression, and AAA information to preserve the session flow in intradomain handover [7]. We consider that context-aware system concepts can also be exploited for the orchestration of MT configuration and adaptation when providing the “persistent transport service” to application flows. 3.2 Approaches of context information representation by profiling Markup languages have been proposed as a basis for context information representation, based on the Resource Description Framework (RDF) or RDF Schema (RDF-S), which improves RDF semantics. For instance, the Composite Capability/Preference Profiles (CC/PP) [8] uses RDF for context information. It defines a “two-level” hierarchy of components and attribute/value pairs for describing a profile of device capabilities and user preferences that can be used to guide the adaptation of the contents presented to that device. CC/PP specification does not mandate a particular set of components or attributes. For instance, the User Agent Profile (UAProf) [5], includes

hardware and software characteristics, application/user preferences, and WAP and network features. 3GPP defines a General User Profile (GUP) [6], a collection of user related data which affects the way in which an individual user experiences high level services. The GUP model information is suitable for representing our “mobile customer” concept, because its structure provides a better organization for introducing complex relationships between elements than the RDF CC/PP approach. However, it uses XML Schema instead of RDF-S. W3C works on semantic web languages as well, and defines the Web Ontology Language (OWL, not an acronym) [9]. An ontology can be defined as "an explicit and formal specification of a shared conceptualization" [10]. OWL expands RDF-S information model adding more vocabulary along with a formal semantics for describing properties and classes, relations between classes, cardinality, equality, richer typing of properties, characteristics of properties, and enumerated classes. Based on this language, OWL-S [11] specifies an ontology of “services” that makes possible functionalities with a high degree of automation to discover, invoke, compose, and monitor Web resources. After considering the benefits that OWL can offer for the context information representation by means of profiles, we have used it to define different kind of profiles (for users, MTs, access network, etc.) following the GUP structure and leveraging OWL features. Even more, we have used OWL-S as a part of the design of a manager of mobility context information that assists the MT in both the access network selection and the persistent transport service configuration.

4 Context-aware system for intelligent access network selection and terminal configuration
In this section we present a high level description of the “Mobility Context Manager Service”, a control plane functional component of the mobile terminal architecture proposed in section 6. It develops three functionalities: the generation of mobility context information, the access network selection and the persistent transport service configuration, i.e., the adaptation and/or re-configuration control of the user data plane when supporting new and ongoing sessions. 4.1 Mobility Context and Persistent Transport Manager Service

The description (presentation, modeling and grounding) of a distributed implementation of the Mobility Context Manager Service (MCMS) (Fig. 1) is made with OWLS. A high level implementation of the service has been developed with the use of the OWL-S Editor [12], an extension of the Protege-2000 [13].

Logical Representation
Access Network Profiles (OWL) Mobility Context Generator (OWL-S) Mobility Context Profile (OWL) Mobile Customer Profile (OWL) Access Network Selector (OWL-S) Persistent Transport Service Configurator (OWL-S) Persistent Transport Service Profile (OWL)





Mobility Context Generator

Access Network Selector


Mobility Context Repository

Persistent Transport Service Configurator


Mobility Context Manager Service

Mobility Customer Repository

Physical Representation

Fig. 1.

Mobility Context Manager Service.

The first task of the MCMS is to generate the mobility context information, i.e., the available ANs and their features in the current MC location. The raw information produced by AN advertisements is transformed into AN Profiles (ANPs), which feed the Mobility Context Generator component. The last is in charge of the creation of an updated Mobility Context Profile (MCP). All profiles have been defined in OWL. The composite process model which describes the main activities performed by the Mobility Context Generator (MCG) is shown Fig. 2.a. The MCG retrieve each ANP in a repeat-while loop. Each ANP is collocated in a provisional list (a container). Finally, the list is processed into a MCP and saved in a repository. The current MCP is used for the Access Network Selection (ANS) process (Fig. 2.b). The ANS is done based in the MCP and the Mobile Customer Profile (MCuP) both of them stored in their respective repositories. The ANS process gets both profile and first it evaluates the current user role and the list of application preferred settings specified in the MCuP according to the role. Then, the ANS process compares the list of application settings with the features of ANs in the MCP, until it finds a suitable network. If there is no a best AN then the ANS process resolves to select one based on default applications settings. Then, the MC establishes the AN association. The last function of the MCMS is the Persistent Transport Service Configurator (PTSC). This component is in charge of the mobile terminal configuration when a new association will be established or there is any change in the mobility context that can modify the current PTS behaviour. The PTSC receives a message form the ANs process advertising the association and requesting for configuration information. The PTSC replies with a Persistent Transport Service Profile (PTSP) (Fig. 2.c), which contains parameters for the configuration of different required components and functionalities of the MT protocol stack. The PTSC interacts with different management systems and servers in the access network in order to retrieve these configuration parameters.





GetMobileClientProfile Start/In

AddAccessNetworkProfileToContainer false VeryfyUserRole ComposePersistentTransportServiceProfile

VeryfyApplicationSettingPreferences true ComposeMobilityContextProfile SelectAccessNetwork false SaveMobilityContextProfile true








Fig. 2.

Process models of Mobility Context Manager Service


Information model of the Mobility Context Manager Service

We model different context-information by means of profiles. These are used as inputs and output of the described Mobility Context Manager Service. The Access Network Profile (ANP) describe the features of one AN organized in a set of profile components groups (PCGs) (Fig. 3.a). The main features included in ANPs were derived from different reports and papers of several standardization groups, such as WWRF, IETF EAP WG, IEEE and 3GPP2, which have deliberated on AN selection issues [14][15]. Each PCG describe a feature that could be relevant during the AN selection before the association establishment: AN identification, QoS (available bandwidth), cost, security/authentication methods, list of intermediary network providers between the current visited AN and the home network, roaming agreements, middleboxes, etc. After the collection of these profiles, the MCG produces a Mobility Context Profile (MCP) which stores context-information of the surrounding heterogeneous environment of ANs. Each PCG is focused in a particular feature such as cost, QoS, etc. and the respective offers of each advertised AN (Fig. 3.b). The MCP is used along with the Mobile Customer Profile (MCuP) by the Persistent Transport Service (PTS) Configurator to produce a PTS profile that guide the adaptation and re-configuration of the terminal protocol stack. The MCuP is composed of a set of PCGs that store information with respect to the user and its preferences per role, default and preferred software settings and terminal hardware and software capabilities. The MCuP is the union of user, application and terminal subprofiles. The “User PCG” includes the criteria of preference used by the user in each of its roles when executing a particular application. The “Application PCG” presents the list of parameter values that must be used for the execution of an application according to the criteria established in the user role.

Network Access (ID1) Profile Network Name (CG) QoS (CG) Cost (CG) Authentication Methods (CG) Intermediary list (CG) Middle Boxes (CG) Interface (CG) a)

Mobility Context (ID #) Profile QoS (PCG) QoS (Acc Net ID 1) QoS (Acc Net ID 2) QoS (Acc Net ID n) Cost (PCG) Cost (Acc Net ID 1) Cost (Acc Net ID 2) Cost (Acc Net ID n) ? ? ?


Fig. 3.

Access Network Profiles and matching Mobility Context Profile.

The last profile of our information model is the Persistent Transport Service Profile (PTSP) which consist of a series of PCGs that enumerate all the parameters that must be set per protocol layer and terminal functional component for the new (or ongoing) data session. All the profiles were edited with the OWL plug-in [16].


Alternative deployments of mobility context manager services

In future 4G scenario the MC should develop for its own the ANs discovery and selection, the mobility context generation and the persistent transport service provision. This MC’s autonomy will be possible only if the mobile device has enough resources and a new business model allows the free association of the MC to any ANs [17]. In this case, the MCMS could be developed in the MC. Current business model requires the user subscription to an Access Network Provider (ANPr), who establishes the association parameters to allow the access to WSs by the MC. This association could be established out of the domain of the original ANPr by means of vertical handover mechanisms and roaming agreements with other ANPrs. In this kind of scenario, the deployment of the MCMS will require the distribution of its components among different entities as the MC, the home and visited ANPs. The Persistent Transport Service Profile (PSTP) could be generated with the collaboration of home and visited ANs and submitted to the MC for its configuration. Fig. 4 presents a simplified sequence diagram of an scenario in which the MC has the ability to perform the Mobility Context Generation (MCG) and Access Network Selection (ANS) tasks, while the Persistent Transport Service Configuration (PTSC) is provided by an agent in the visited AN. The ANs advertise their features which are collected by the MT network interfaces. The MCG composes a mobility context profile that is used during the ANS process. In this step, the ANS process evaluates the user and application needs and compares them with the MCP selecting the best offered AN. Then, the MC associates itself with the chosen AN (sequence not shown in the figure). The MC localizes the PTSC component service in the access network

following the URL announced in the AN profile, or alternatively, it could ask for it to a UDDI registry. The MT sends a message to the PTSC requesting a specific PTS profile. The PTSC interacts with other servers to collect all the configuration parameters that will be necessary to access the pretended service over the AN. Finally, MT receives an answer with the requested PTSP which allows it to access the WSs.

Fig. 4.

Interaction between the components of Mobility Context Manager Service.

To provide the required flexibility of the service deployment, we take advantage of semantic web solutions. Offering the mobility context management service at high level allows overcoming interoperability problems in heterogeneous systems.

6 Terminal Architecture Proposal for 4G networks
We have proposed a TCP/IP-based mobile terminal architecture, suitable for future heterogeneous integrated networks, based on a generic reference model (BRENTA) [18]. The architecture is divided in two main planes, the User Data Plane and the Control Plane, as shown in Fig. 5. In the user data plane (“or network plane”), different kind of applications from Internet legacy applications (Web, mail, etc) to adaptive and QoS-aware applications relay in a generic interface, the “Common QoS Interface” (CQoSI) [3] to request Hard and QoS support independently of the underlying QoS technologies. The “QoS Processor” translates these parameters to network level QoS parameters according to the available QoS Service Provider (QoSSP). It provides an adaptable and reconfigurable transport service to active sessions during the MC displacement, and implements, maintains, and handles specific QoS signaling. The “Transport Service Provider” encompasses transport protocols (UDP or TCP), QoSSPs and networking functionalities, and is in charge of the association with access network which offer

Internet connection services based on IP parameters (IP addresses, default routers, etc). An “Enhanced Network to Link layer interface” provides a standard link layer interface for different underlying link technology. In the Control Plane, the MCMS orchestrates the functionalities and resources of the mobile terminal as commented before.
Mobility Context Manager Service

QoS Aware and/or Adaptable Applications

Legacy Applications

Common QoS Interface
QoS Parameter Mapper QoS Primitives Mapper QoS Snifferr

Control Plane

QoS Mapper





QoS Service Provider

IP (v4/v6)

Ad Hoc Routing

Mobility Support

Enhanced Network to Wireless Interface

Transport Service Provider

Wireless Link Technologies ( e.g., 802.11, UMTS, Bluetooth )

Fig. 5.

Proposed TCP/IP-based Terminal architecture for 4G networks.



Future 4G Networks impose fundamental requirements in mobile user’s terminal such as cross-layer and TCP/IP-based design; QoS, multi-homing and mobility support; adaptation and re-configuration at different level of the protocol stack, etc. In this paper we had presented a high level description of a context-based management distributed service and profiling system proposed for allowing the user terminal to support a persistent transport service for mobile user’s applications in such networks. The distributed system (the MCMS), is part of the terminal control plane and it is used for the configuration control of the terminal during vertical handover process and roaming. The MCMS is a context-based service composed of three basic components for the collection of information related to the surrounding access networks, the access network selection and the terminal configuration for persistent transport service. These components exchange context-based information of the mobile costumer in form of profiles, and we have proposed the use of ontology languages, such as OWL, to define our information model after the analysis of several approaches. Even more, we have described each service component by means of OWL-S, an ontology based on OWL to discover, invoke, compose, and monitor service resources. This method allows a faster and easer deployment of MCMS in future scenarios where

mobile terminal should be more autonomous. Lastly we propose a TCP/IP-based terminal architecture for 4G networks.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Pereira, J. “European Approach to Fourth Generation –A personal perspective”. International Forum on 4th Generation Mobile Communications. London, UK. May, 2002. I.Ganchev et al. “Requirements for an Integrated System and Service 4G Architecture”, IEEE Semiannual Vehicular Technology Conference, May 17-19, 2004, Milan, Italy. I. Armuelles, T. Robles, D. Fernández. “Componentes Funcionales de Middleware para un Terminal Móvil de Redes de Comunicaciones Móviles de 4G”. XIX Simposium Nacional de la URSI. Barcelona. Espa?a. Septiembre, 2004. Dey, A. K. (editor), "Providing architectural support for building context-aware applications," Ph.D. dissertation, College of Computing, Georgia Institute of Technology, Georgia, USA, 2000. “User Agent Profile”. Version 2. Open Mobile Alliance. May, 2003. “3GPP Generic User Profile (GUP); Stage 2; Data Description Method; (Release 6)”. Technical Specification. 3GPP TS 23.241 V1.0.0. December, 2003. J. Loughney (editor) et al. “Context Transfer Protocol”. Internet Draft. IETF Seamoby WG. August 2004. “Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0”. W3C Recommendation 15 January 2004. D. L. McGuinness et al. “OWL Web Ontology Language Overview”. W3C Recommendation. February, 2004. R. Studer, V.R. Benjamins, D. Fensel: Knowledge Engineering: Principles and Methods. Data & Knowledge Engineering. 25. (1998) 161-197 “OWL-S: Semantic Markup for Web Services”. W3C Member Submission 22 November 2004 G. Denker, D. Elenius, and D. Martin. “OWL-S Editor”. Third International Semantic Web Conference - ISWC 2004, Hiroshima, Japan. November, 2004. N. F. Noy et all. “Creating Semantic Web Contents with Protege-2000”. IEEE Intelligent Systems 16(2):60-71, 2001. J. Arkko and B. Aboba, (editors). “Network Discovery and Selection Problem”. InternetDraft. IETF EAP WG. July 17, 2004 R. van Eijk, J. Brok, J. van Bemmel, B. Busropan, “Access Network Selection in a 4G Environment and the Roles of Terminal and Service Platform”, WWRF #10, 27-28 October 2003, New York. H. Knublauch, R. W. Fergerson, N. F. Noy, M. A. Musen.“The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications”. ISWC 2004, Hiroshima, Japan. November, 2004. M. O'Droma and I. Ganchev. “New Access Network Techno-Business Model for 4GWW”. In Proceedings of 4th ANWIRE International Workshop on Wireless Internet and Reconfigurability, 7 pages, 14 May 2004, Athens, Greece. A. Kassler et al. “Enabling Mobile Heterogeneous Networking Environments With Endto-End User Perceived QoS - The BRAIN vision and the MIND approach”. European Wireless Conference 2002. Florency, Italy. February, 2002.

...Management of Mobility Context Information for A....pdf
Profile System for Management of Mobility Context Information for Access Network Selection_专业资料。Abstract. High level services and data transport service ...
...Results of a Mobile Terminal for Heterogeneous S....pdf
mobility management concept, this paper will focus...System for broadband Ubiquitous access to InTErnet ...Link information for each segment (segment indicator...
...and Access Control Agent Framework for Context-A....pdf
system implementation as one of the context-aware...access control agent framework for context-aware ...management server, user profile management server)....
Federated management of information for TeleCARE.pdf
Federated management of information for TeleCARE_...for TeleCARE provides the MAS, mobility, safe ...Profile System for Man... 10页 免费 Security...
...of the BRAIN candidate mobility management proto....pdf
system are mobility management and quaility of ...context of micro mobility in an access network, ...for installing information in the interior of the...
...for Network-Based Localized Mobility Management (NETLMM)_....pdf
(NETLMM) Status of This Memo This memo provides information for the ...Localized Mobility Management Domain An Access Network in the sense defined in...
Media Independent Handover for Seamless Mobility in....pdf
all types of networks of heterogeneous system. Multiple...methods for mobility management at IP layer [2]...Only the context (access control, QoS profile ...
Mobility management extensions in the wireless ATM ....pdf
of a mobility management protocol that would ...profile for these MTs, it replies to inquiries ...[BAU96], to obtain useful information for the ...
...of Mobility Management Approaches for IPv6 based....pdf
Eberhardt “ Evaluation of Mobility Management ...Ubiquitous access to Internet has to be provided ...Profile System for Man... 10页 免费 ...
...Based Networking in the Integration Effort of 4G....pdf
profile can have public and private information: ...control of the user terminal (mobility client). ...a need for a complex AAA and billing system. ...
On the analysis of cellular IP access networks.pdf
On the analysis of cellular IP access networks_...of mobility management signaling information and ...Pautet, “The GSM System for Mobile ...
P2P-based Mobility Management for Heterogeneous Wir....pdf
P2P-based Mobility Management for Heterogeneous ...Context-Aware Homes, " Proceedings of the ...Mutka, “Efficient Mobile Access to Internet Data...
WES7 SP1_选项列表中英文对照表.doc
Profile __.NET Framework 3.0 __.NET Framework ..._Management __System Management ___Group Policy ...of Service __Remote Access Service(RAS) __Small...
Mobility Management Entity Non-Access Stratum Policy...Profile Repository Tracking Area Tracking Area ...information of the user, which is required for ...
Windows Embedded Standard 7 SP1.doc
__.NET Framework 2.0 Client Profile __.NET Fra..._Management __System Management ___Group Policy ...of Service __Remote Access Service(RAS) __Small...
Windows Embedded Standard 7 SP1 选项列表中英文对照.xls
__.NET Framework 2.0 Client Profile __.NET Fra...of Service __Remote Access Service(RAS) __Small...systemmanagement-utilities.cab winemb-system...
Windows Embedded Standard 7 SP1 选项列表中英文对照_....doc
Profile _.NET Framework 3.0 _.NET Framework 3.0..._Management _System Management _Group Policy ...of Service _Remote Access Service(RAS) _Small ...
JUNIPER TRAPEZE WLAN Configuration by using RingMas....pdf
Quickstart to make HW available for management IV...Sort Access Rules ? Auto-AP ? 802.1X timers ...www.juniper.net 802.1X SERVICE: RADIO PROFILE ...
【操作系统】Wes7组件功能说明 - 嵌入式Win7 - Windows....pdf
__.NET Framework 2.0 Client Profile __.NET ...只能安装) _Management __System Management ___...__Quality of Service __Remote Access Service(RAS...
Content adaptation on LANE active network platform.pdf
the key issues are support for mobility, security...management logic of the system is located in MAS...The profile contains user information such as a ...

All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。