1. Ericsson, ALLIP-20000717-0071 Features control at Home or at the Visited Systems.

2. 2 In the early days of cellular, the switch (MSC) did everything:  Switching the calls  Handling air interface (e.g., intersystem handoff, paging)  Functionalities (e.g., call forwarding busy) Features Control_Historical background 2.1.1Cellular early days: the switch does everything

3. 3 Consequences:  The functionalities of the cellular system are closely bundled, as the MSC does everything (e.g., traffic, handoff, features)  System had many interdependent functionalities, with non standardised interfaces  As the system is "home" centric, features are not available in any "visited" system (manual roaming) Features Control_Historical background 2.1.1Cellular early days: the switch does everything

4. 4 Realizing that the limitations of the monolithic switch (MSC) approach, the cellular system got subdivided in its basic functionalities:  MSC: switching calls, handover  VLR: data cache  HLR: features  AC: authentication ... Features Control_Historical background 2.1.2The monolithic switch is decomposed in sub functions

5. 5 Consequences:  with concept of visited MSC, a roamer can access locally defined features (e.g., features that he can't access when home)  the roamer can as well have access to some of his home features, providing that the feature codes he used to access them were not already used by the visited system, and that the visited system would agree to receive directives from the home. –(e.g., if the user's service provider defines he activates Do Not Disturb by dialling *53, and if the visited service provider locally defined *53, the roamer will not succeed to activate DND while dialling *53) Features Control_Historical background 2.1.2The monolithic switch is decomposed in sub functions

6. 6 Consequences:  features development requires manufacturers to upgrade many of the cellular nodes (e.g., MSC, VLR, HLR, AC), even the ones that should be handling traffic only  upgrading software in the cellular nodes requires careful juggling (e.g., connecting an IS41C compliant HLR to an IS41A compliant MSC, even though possible, results in very limited services offering to the mobile user) Features Control_Historical background 2.1.2The monolithic switch is decomposed in sub functions

7. 7 Wireless Intelligent Network approaches were developed. These were heavily influenced by the PSTN Intelligent Network development and, in Europe, CAMEL The Service Switching Function (SSF) function was to host the call model, and to present to the Service Control Function (SCF) a simple set of triggers from which one could build features. MSC resident SCP (or HLR) resident The intent was to have all manufacturers implementing an SSF that would offer to all the SCFs the same triggers and behaviours. Features Control_Historical background 2.1.3 Wireless Intelligent Network: rescuer of the features

8. 8 Consequences :  For the WIN concept to work, the SCF needs to get from the SSF a set of detection points with stable and predictable functions  For the WIN concept to work, the SCF needs to interface with the SSF via a well defined and stable interface  As in real life the SCF was connected to SSFs produced by various manufacturers, with different functionality levels - detection points-, and using diverse versions of the protocol, the WIN promises were compromised. Features Control_Historical background 2.1.3 Wireless Intelligent Network: rescuer of the features

9. 9 Looking back, we can assess that we learned the following lessons:  It is part of the cellular user's nature to roam. He must then acquire geographical independence when he needs to access to his features.  Current cellular networks do not separate "features" from "access networks". Even though this division is more visible in each of the historical evolution steps, the connection between access (through the visited system) and features (provided from the home) is still tight. Features Control 2.2 Today, features wise?

10. 10 Unbundling features from the access is the way out. The intent is to ensure that the user has access to "all" his features, regardless of his physical location. Two models apply. In both, the visited system handles access.  Visited control: The home system may delegate handling of features execution to the serving.  Home control: The home system handles features execution. Features Control 2.3 Way out

11. 11 We will look at these models, but lets first define some basic terms.  Personalized features: features that are offered by a home service provider to his subscribers, who elect to subscribe to the ones of interest. Example: Do Not Disturb.  Localized features: features that are offer by a service providers to the users that happened to roam in this area. These features depend on local execution. Example: emergency service call (e.g., 911, 112). Features Control 2.3 Way out_ Definitions

12. 12  Home: –In a strict TR45.2/ANSI41 context, "home" refers to the physical location where the MS user can find his HLR. When roaming, the visited systems direct their registration signalling to the user's home. –Only signalling transit by the home. Traffic (e.g., trunks) does not. –In the context of this paper, we define the notion of "home" as any physical arbitrary location where the user's service provider want to send the user's "registration" signalling, and from which he wants to provide features. This may mean that my home is Montreal when I am at the office, and in Brussels when I am roaming there. –Only some signalling transit by the home. Traffic (e.g., trunks/bearer) does not. Features Control 2.3 Way out_ Definitions

13. 13 As a continuation of the current TR45.2/ANSI41 model, personalized features can be executed by the visited system. A service provider may use to ensure that the point of service execution is as close as possible to the user's point of presence. Features Control 2.3.1 Way out_Visited System

14. 14 Visited control requires that:  The home provides to the serving the "programs" and data needed to process the features. They may be statically provisioned… but seems unrealistic.  Optionally, one could define a mechanism of transfer (aplets) between the home and serving. The serving becoming a generic service execution platform. This option seems would mean that the service provider owning the visited system accepts to have his resources used by unknown features.  Regardless of the technique used, it requires that a set of interfaces is defined between the home and the serving, to ensure proper features processing and exchange of information. Features Control 2.3.1 Way out_Visited System

15. 15 A service provider may decide to go with this option in order to ensure that the user will have access to his features, regardless of his point of presence. Home control:  The home does not have any expectations from the serving (e.g., in terms of interfaces & protocols, provisioning of the serving with the proper version of the software), as the serving solely acts as a proxy, relaying signalling from the user to his home. Features Control 2.3.2 Way out_Home control

16. 16 Home control (cont’d):  The home provides the "programs" and data needed to process the features. This may have been statically provisioned.  Optionally, a mechanism of transfer (aplets) is defined between the homes. These “other” homes would be under direct control of the user's service provider so that "cannibalizing" of serving resources would not be an issue.  Some services (e.g., emergency services, local directory calls) could be handled from the visited.  Similarly, the serving system proxy the registrations to the home system, as the home is in control of all terminating calls Features Control 2.3.2 Way out_Home control

17. 17 3GPP elected to allow both methods to coexist, as long as the home control is compulsory. This makes sense as, upon user registration (e.g., via subscriber profile, or home policy related), the home may decide to remain in control, or to adopt the serving control method. Features Control 2.3.3 Way out_Method to use?

18. 18 Conclusion 3GPP2 all-IP Network Architecture Model should be designed in such a way that access networks is separated from features execution. Access should be a serving system issue. Handling traffic (bearer). Features could be controlled either via the home, or the serving system. Decision is left to the home (e.g., home control is compulsory). Only signalling exchanged (e.g., no traffic/bearer) When home control is selected, the home does not expect any features from the serving which acts as a proxy. There are exceptions (e.g. emergency and local directory calls).