Implementation of UPT Service in WIN-Based Mobile Communication Networks
Yun Won Chungo, Min Young Chungy , Dan Keun Sung , In Jeong Kimz , Jung Keum Shinz , and Sung Kimz CNR Lab., Dept. of EE, KAIST, 373-1 Kusong-dong Yusong-gu, Taejon 305-701, Korea y Switching & Transmission Technology Lab., ETRI, 161 Kajong-dong Yusong-gu Taejon 305-350, Korea z Network Development Team, SK Telecom, 267 Namdaemunno 5-ga Chung-gu Seoul 100-095, Korea
[email protected]
Abstract
This paper describes an Intelligent Network (IN) concept in mobile communications and shows the implementation of personal mobility in mobile communication networks. Even though the current Wireless Intelligent Network (WIN) protocol does not accommodate Universal Personal Telecommunication (UPT) service, we design UPT service in the WIN. We assume that service pro le and location information of UPT user are managed in service control point (SCP) and the relationship between UPT number (UPTN) and the identity of mobile terminal (MT) at which the UPT user is incall registered is stored in the SCP. In particular, we focus on incall delivery to a UPT user based on the service pro le of UPT user, not to that of MT in case of failed call setup situations such as busy and no answer. This study can be utilized in the implementation of UPT service in WIN-based mobile communication networks.
1 Introduction
The ultimate goal of mobile communication services is to provide information at any place, at any time, to any person, in any form in the world. This can be realized through the provision of terminal mobility, personal mobility, and service portability [1], [2]. Terminal mobility is the ability of an MT to access telecommunication services from any place and the capability of the network to manage the location of the MT. Personal mobility is the ability of a user to make and receive calls and access telecommunication services at any MT in any place by the use of unique personal number associated with the user instead of the MT. Service portability is the network capability to provide telecommunication services at the terminal and place speci ed by the user and is provided through the management of service pro le. Many papers have focused on terminal mobility and they promoted the development of mobile communication services. Mobile communication has evolved from the rst generation analog cellular systems such as Advanced Mobile Phone System (AMPS) in North America to the second generation digital cellular systems such as Global System for Mobile (GSM) in Europe. These mobile communication systems mainly support voice calls and low rate data services. Recently, many studies have been worked on the development of third generation mobile communications systems such as the International Mobile Telecommunications - 2000 (IMT2000). The IMT-2000 is intended to support full mobility service, which is provided by integrating terminal mobility, personal mobility, and service portability.
The full mobility is realized by the use of IN concepts which separates call control and service control [3], [4]. Applying IN concepts to mobile communication networks has been carried out in several standardization bodies, particularly in standardization bodies such as Telecommunication Industry Association (TIA) and European Telecommunication Standard Institute (ETSI). TIA and ETSI developed WIN and Customized Applications for Mobile network Enhanced Logic (CAMEL), respectively. WIN introduces IN concepts into existing Interim Standard - 41 (IS-41) network standards and allows network operators great exibility in terms of service creation and service control platforms [5]. CAMEL attempts to superimpose IN functionality on the existing GSM networks [6], [7]. CAMEL adapts existing GSM MAP protocol and overlays IN protocol for CAMEL services. Therefore, IN service and mobility speci c signaling are maintained separately in CAMEL. A few studies on personal mobility have been carried out [1], [8], [9], [10]. In particular, in the International Telecommunication Union - Telecommunication standardization sector (ITU-T), UPT service was proposed to realize personal mobility in xed networks. UPT is de ned as a service that enables access to other telecommunication services while allowing personal mobility [11], [12]. It enables each UPT user to participate in a user-de ned set of subscribed services and to initiate and receive calls on the basis of a personal, network transparent UPTN across multiple networks. In addition, UPT is a particularly attractive concept from the viewpoint of those users who, while roaming among networks, want to be reached by other users as if they are in the home network. Since UPT is developed
based on the xed network, in which the location of terminal is xed, it cannot be applied in mobile networks directly. Therefore, it is needed to take into account of the mobility of an MT in order to implement UPT service in the mobile network. Yabusaki et al. proposed two level database hierarchy visitor location register (personal) (VLR(P)) and home location register (personal) (HLR(P)) for UPT user's personal mobility management [2]. When a UPT user wants to be incall registered at an MT, he needs to make a user location registration to associate his UPTN with the identity of MT in the VLR(P). Then, the VLR(P) sends location registration request to HLR(P) and the relationship between UPTN and VLR address is stored in HLR(P). However, in this management scheme, UPT user data in VLR(P) and HLR(P) must be updated whenever the MT at which the UPT user is registered performs location update and this results in signaling load in the signaling network and location registers. In this paper, we manage UPTN and identity of MT at which UPT user is incall registered in SCP. If a call is made to the UPT user, the identity of MT at which the UPT user is incall registered is retrieved from SCP and using this identity, we can deliver this call to the UPT user. Based on this personal mob ility management scheme, we design UPT service based on WIN. This paper is organized as follows. Section II describes the WIN concept and introduces UPT service. In Section III, we design UPT service procedures based on WIN protocol. Finally, conclusions are given in Section IV.
2 WIN and UPT Service 2.1 WIN
WIN is a concept being developed by the TIA standard committee TR45.2. and the aim of this committee is to drive IN capabilities into wireless networks based on IS41. WIN enables a graceful evolution to an IN without making current network infrastructure obsolete. WIN supports the use of intelligent network capabilities to provide seamless terminal services, personal mobility services and advanced network services in mobile environment [5]. Terminal mobility services are services created using IN capabilities to serve customers with mobile terminals. Personal mobility services are services created using intelligent network capabilities to serve customers who are mobile. Advanced network services have the functionality to identify the capablity of the serving network, to provide service based on the network and the terminal capability, and to provide seamless service mobility between wireless and wireline networks. Fig. 1 shows the wireless intelligent network model. The model consists of base transceiver station (BTS), base station controller (BSC), mobile switching center / service switching center (MSC/SSP), intelligent peripheral (IP), VLR, HLR, and SCP. The BTS consists of one or more tranceivers placed at a single location and terminates the radio path on the network side. The BTS may be colocated with a BSC or may be independently located. The BSC is the control and management system for one or more BTSs. The BSC exchanges messages with both the BTS and the MT. Some signaling messages may pass through the BSC
transparently. The MSC/SSP performs the necessary switching functions required for the MTs located in an associated geographical area. It also detects IN service requests and provides IN service switching functions. The SCP contains IN service logic and performs IN service request from the MSC/SSP. The IP is used to communicate with the users. It can be used for voice recognition, digit receiving for communicating with one or more MSC/SSPs.
2.2 UPT Service
UPT is a service concept which provides personal mobility and service mobility to end users. In the UPT service environment, each user will be assigned a unique personal number (UPTN) which will be dialed by calling subscribers to reach the UPT user, and also used to identify the UPT user at the time of a service request. Through manipulation of the service pro le, the UPT user will not only be able to designate speci c terminals ( xed or mobile) for call delivery and call origination but will also be able to invoke such subscribed supplementary services as call forwarding on busy or no answer situation. The speci c services and features available to a UPT user as he roams across di erent networks and uses di erent terminals will, of course, depend on the capabilities of the terminal as well as the network serving the terminal. UPT service consists of four essential UPT features and many optional UPT features. Essential UPT features are those features which are part of the basic operation of UPT and are therefore considered essential for UPT implementations. Essential UPT features include UPT user identity authentication, InCall registration, outgoing UPT call, and InCall delivery. Optional UPT features are additional UPT features that provide enhancements to the basic operation of the UPT service. UPT may enable access to the optional features, limited by terminal and network capabilities and restrictions imposed by the network provider. Optional UPT features include remote InCall registration, OutCall registration, OutCall follow on, global follow on, and AllCall registration, etc. We consider four essential UPT features, outCall follow on, global follow on, and forwarding of InCall delivery on busy or no answer situation.
3 UPT Service based on the WIN In this section, we provide UPT service procedures based on the WIN. We assume the following: We manage the service pro les of UPT users in SCP. The relationship between UPTN and the identity of MT at which UPT user is incall registered is stored in the service pro les of UPT users in SCP. All the control related to a call is processed in the originating MSC/SSP for simplicity of call control and eciency of routing in case of forwarding. Therefore, if a call to a UPT user needs to be forwarded to another MT, the call path is made from the originating MSC/SSP to the forwarded MT.
Incall to a UPT user is handled based on the service pro le of the terminating UPT user, not that of MT at which the UPT user is incall registered. With above assumptions, we design each UPT service procedures.
3.1 UPT user identity authentication
This is a feature by which UPT service provider veri es that the identity of the UPT user is the one claimed. It protects the UPT user and the UPT service provider against unauthorized and fraudulent use. This feature may be used in each UPT procedure. Fig. 2 shows the UPT user identity authentication procedure. When a UPT user wants to perform UPT features such as incall registration or outgoing UPT call, he/she rst dials UPT access code (UPTAC) to access UPT procedures. Upon receiving UPTAC, MSC/SSP sends a message to an SCP notifying that a trigger value in the Analyzedinformation detection point (DP) has been satis ed. The SCP detects that the access of UPT feature is requested and determines that an IP is required to identify the caller. The SCP sends a request to IP to allocate a bearer resource between the IP and the MSC/SSP. The IP returns a temporary local directory number (TLDN) to the SCP and the MSC/SSP routes the call to the IP using the speci ed TLDN. Through the interaction between UPT user and the IP the SCP receives caller's UPTN and authentication code and checks the validity of UPT user. If the validity succeeds, UPT procedure identi cation is performed as described in the next section.
3.2 UPT procedure identi cation
Procedure identi cation follows after successful UPT user identi cation and authentication. Fig. 3 shows the UPT procedure identi cation. In this procedure, UPT user sends the code for procedure which he wants to perform and SCP performs the UPT user's service pro le check whether the UPT user is allowed to use a particular procedure requested or not. If it succeeds, the following UPT features are performed.
3.3 InCall registration
This is a feature that enables the UPT user to register from the current terminal address for incoming calls to be presented to that terminal address. When registered, all incoming calls to the UPTN will be presented to the registered terminal address. Fig. 4 shows the InCall registration procedure. This procedure follows from the UPT procedure identi cation. When the user dials the code for the inCall registration in Fig. 3, SCP updates the relationship between UPTN and identity of MT at which the UPT user wants to be incall registered in the UPT user's service pro le. After the update, the SCP sends an acknowledgement announcement through IP and requests a new procedure or termination by global follow-on feature. If the UPT user wants to terminate, the call between the MSC/SSP and the IP is released and the inCall registration feature is ended. If the UPT user wants to perform a new UPT procedure, the network performs UPT procedure identi cation again and the UPT user requested feature is
carried out. However, in this case, the UPT user identity authentication procedure is unnecessary.
3.4 Outgoing UPT call
This is a feature by which the UPT user can initiate, from any terminal, an outgoing UPT call attempt. This feature requires UPT user identity authentication for each outgoing UPT call attempt. Fig. 5 shows the outgoing UPT call with outCall follow on procedure. This procedure follows from the UPT procedure identi cation. When the user sends the code for the outgoing UPT call in Fig. 3, SCP sends an announcement message for destination number and receives it through IP. Using this number, network performs an incall delivery procedure. If the destination number is UPTN, the procedure is performed, as shown in Fig. 6 and if the destination number is the same as the MT number, it follows a general mobile call setup procedure. If the terminating party releases the call, the originating MSC/SSP detects it, sends outCall follow-on request to the SCP and a new outgoing call or a new procedure is performed without further authentication.
3.5 InCall delivery to a UPT User
This is a feature by which incoming calls are presented at the terminal address registered previously by InCall registration. This feature is invoked when originating parties or others call the UPT user. Fig. 6 shows the inCall delivery to a UPT user procedure. A mobile user sends a call origination request with destination UPTN. Upon receiving UPTN, MSC/SSP sends a message to an SCP notifying that a trigger value in the Analyzedinformation DP has been satis ed. The SCP detects that the call delivery to UPT user is required and using the relationship between the UPTN and the identity of MT. Then the SCP sends a service request for incall delivery to a UPT user to the HLR of mobile terminal at which the UPT user is incall registered. The HLR sends a route request to the VLR at which the MT is location registered with the termination triggers (TERMTRIG) parameter of terminating UPT user. The TERMTRIG parameter de nes the termination trigger points that are currently active for subscribers. The VLR sends this request to the serving MSC/SSP. The serving MSC/SSP checks the state of the MT and if it is not busy, the MSC/SSP returns acknowledgement of route request with TLDN. At this time, TERMTRIG of terminating UPT user is stored in the serving MSC/SSP and the call to the UPT user is handled by this TERMTRIG parameter. HLR sends an acknowledgment message of service request to the SCP and the SCP sends a terminationlist (TERMLIST) to the originating MSC/SSP and the call is made from the originating MSC/SSP to the serving MSC/SSP. The procedure of remaining parts of call setup to terminating UPT user is the same as the normal mobile call setup procedure.
3.6 Forwarding of InCall Delivery to a UPT User on Busy
If the MT at which a called UPT user is incall registered is busy when a call setup request is sent to the serving MSC/SSP, the following procedure is performed, as
shown in Fig. 7. The originating MSC/SSP sends a call setup request to the serving MSC/SSP. In this case, the MT is busy and the serving MSC/SSP sends a redirection request to the originating MSC/SSP. This is possible by the TERMTRIG parameter which was downloaded to the serving MSC/SSP in the route request shown in Fig. 6. If this parameter is not downloaded, the serving MSC/SSP performs call forwarding based on the MT's service pro le instead of UPT user's service pro le using the traditional mobile call setup protocol and this result in undesirable call delivery. This is important because the calling user does not want to setup the call to the MT. Instead, the user wants to setup the call to the UPT user. Therefore, network must process the call setup based on the UPT user's service pro le. We download TERMTRIG to the serving MSC/SSP and if any failed call setup situation such as busy and no answer occurs, the serving MSC/SSP send the control of this call to the originating MSC/SSP using a redirection request. The call path between them is released and the originating MSC/SSP sends TBUSY to SCP to obtain call treatment instructions from SCP. The SCP checks the UPT user's service pro le, sends a forwarding number and the call setup is performed by using this information. Fig. 8 shows the implementation of the procedure in the basic call state model (BCSM)
[6] ETSI GSM 02.78 Version 6.1.0, \Digital Cellular Telecommunications System (Phase2+); Customized Applications for Mobile network Enhanced Logic (CAMEL) Service definition - stage 1", July 1998. [7] ETSI GSM 03.78 Version 6.2.0, \Digital Cellular Telecommunications System (Phase2+); CAMEL Phase 2: stage 2" Nov. 1998. de nition - stage 1", July 1998. [8] Conor Morris and John Nelson, \Architectures and Control Issues for the Support of UPT in UMTS," Globecom'96, pp. 2063 - 2067, 1996. [9] Marie-Pierre Gervais and Bijan Jabbari, \A Framework for Mobility in Wireless Personal Communications," ICC'96, pp. 1148 - 1152, 1996. [10] Ling-Sheng Chen, \Apply Personal Mobility in PCS Environment for Universal Personal Communications," ICUPC'96, pp. 503 - 507, 1996. [11] ITU-T Recommendation F.850, \Principles of universal personal telecommunication(UPT)," Mar. 1993. [12] ITU-T Recommendation F.851, \Universal personal telecommunication(UPT) service description (service set 1)," Jan. 1994.
SCP
4 Conclusions
We described an IN concept and implementation of personal mobility in mobile communication networks. Then, we designed UPT service based on WIN protocol assuming that service pro le and location information of UPT user are managed in SCP and the relationship between UPTN and the identity of MT at which the UPT user is incall registered is stored in the SCP. In particular, we mentioned incall delivery to UPT user according to the service pro le of UPT user, not to that of MT in case of failed call setup situations such as busy and no answer. This study can be utilized in the implementation of UPT service in the WIN based mobile communication network.
Acknowledgement
This study was supported in part by the SK Telecom.
References [1] Yukio Kawanami, \Road Map to Universal Personal Telecommunication in Public Land Mobile Network Environment," ICUPC'95, pp. 538 - 542, 1995. [2] Masami Yabusaki and Akihisa Nakajima, \Network Issues for Universal Mobility," IEICE Trans. Fundamentals, vol. E78-A, no. 7, pp. 764 - 771, July 1995. [3] Margaret Britt, \Convergence and the Wireless Intelligent Network," ISS'96, pp. 81 - 87, 1996. [4] Nadege Faggion, \Intelligent Networks in Mobile Communications," ICIN'98, pp. 106 - 111, 1998. [5] WIN TIA/EIA IS-41.D, \Cellular Radio Telecommunications Intersystem Operations," May, 1998.
signaling system
HLR
MSC/SSP
VLR
IP
BSC BTS
BTS
BTS MT
Figure 1: WIN network model
MSC/SSP
SCP
IP
Call Origination[UPTAC]
1 2 3
ANLYZD[DGTSDIAL,TRIGTYPE] SEIZERES[SRFCAP] ANZT
seizeres[TLDN]
SRT
CONNRES[TLDN] TLDNAT Call Setup
4 5
WINRT
6 INSTREQ
7 SRFDIR[ANNLIST]
IRT
8 Provide your Identity
9 UPT Number
SRFDT
10 srfdir[DGTSDIAL]
11 SRFDIR[ANNLIST]
SSFT
12 Provide your authentication code authentication code
13
SRFDT
14 srfdir[DGTSDIAL]
15
Figure 2: UPT user identity authentication
MSC/SSP
SCP
IP SRFDIR[ANNLIST]
Originating MSC/SSP
16 Identify procedure
HLR
SCP
Serving MSC/SSP
VLR
17 Call Origination
SRFDT
code for procedure
18
1
srfdir[DGTSDIAL]
ANLYZD[DGTSDIAL,TRIGTYPE]
19
SSFT
2 SERVREQ[ServiceID,IMUI]
Service Profile Check (SCF SDF)
3
20 ROUTREQ[IMUI,TERMTRIG] ROUTREQ[IMUI,TERMTRIG] RRT
SVRT
ANZT
RRT routreq[TLDN]
routreq[TLDN]
Figure 3: UPT procedure identi cation
4 5 6 7
servreq[ActionCodeList]
8 anlyzd[TerminationList, TriggerAddressList]
9
Call Setup
MSC/SSP
HLR
SCP
10
IP
Service Profile Update (SCF SDF)
Figure 6: InCall Delivery to a UPT user
21
SSFT SRFDIR[ANNLIST]
22 23
Acknowledgement or information
Indicate new request is required or terminate
24 SRFDT
termination request
25 srfdir[DGTSDIAL]
26 anlyzd[ActionCodeList, TerminationList]
27 IRT Call Release
28
Originating MSC/SSP
HLR
SCP
Serving MSC/SSP
VLR
instreq
29
MS becomes Busy
Call Setup
Figure 4: InCall registration with global follow-on
10
11
REDREQ[Reason=Busy]
12 RDRT
redreq
13
Call Release
14
MSC/SSP
SCP
IP
TBUSY[Reason=Busy]
15 TBT
tbusy[ACTCODE,TERMLIST]
16
SRFDIR[ANNLIST]
21
Call Setup
17
Supply destination number
22 SRFDT
destination number
23 SSFT
srfdir[DGTSDIAL]
24
anlyzd[ActionCodeList,TerminationList] IRT Call Release
25
Figure 7: Forwarding of InCall Delivery to a UPT user on Busy
26 instreq
27 28
InCall delivery & Conversation
Release Request
29 TSUSPEND
30 31
SEIZRES SRT
TST
Originating System
Serving System
MSC/SSP
MSC/SSP
seizres
32 33
CONNRES[TLDN]
T-BCSM 1
O-BCSM 3
HLR
SCP
VLR
O-BCSM 2
SACF
T-BCSM 2
Call Setup
34 INSTREQ SRFDIR[ANNLIST]
Term._Auth. DP
35 REDREQ[Reason=Busy]
IRT
36 37
Send_Call
Call Release T_Exception
SRFDT
Response = YYY
Select_Facility
redreq Present_call
Enter XXX for new procedure or YYY for new call
T_Busy DP
38
TBUSY[Reason=Busy]
srfdir[DGTSDIAL]
T_Null
tbusy[ACTCODE,TERMLIST]
39
O_Called_Party_Busy DP
SSFT SRFDIR[ANNLIST]
40 O_Exception
Supply destination number
41 destination number
O_Null
SRFDT
42 Select_Facility
O_Null
Orig_Attempt DP
srfdir[DGTSDIAL]
43 44
tsuspend
Auth._Orig._Att
IRT
Call Release
45 instreq
46 InCall delivery & Conversation
47
Figure 5: Outgoing UPT Call with outCall follow-on
Figure 8: BCSM of Forwarding of InCall Delivery to a UPT user on Busy
