Content for TR 22.802 Word version: 14.0.0

0… 4… 5…

4.1 Automotive 4.2 In-vehicle User Equipment 4.3 Provision of an International M2M Service for a Business Customer

4 Use cases p. 6

4.1 Automotive p. 6

4.1.1 Use Case Description p. 6

The mobile service provider needs to support an automotive service provider that uses different applications with distinct connectivity needs, QoS requirements and billing profiles. As the ME is a non-trusted equipment the MNO utilizes network based features to avoid application misusage of lower cost connectivity.

4.1.2 Pre-conditions p. 6

The automotive service provider uses 3 different applications:

A car diagnostic application that is regularly connected to an application server to send diagnostic data;
An anti-theft application that requires a data connection to an application server only when triggered by specific events with strict SLA, e.g. delivery of theft alert within x seconds;
A customer care service that uses both voice and data traffic that has a specific billing profile.

All the applications can be active at the same time.

The mobile service provider provides different levels of characteristics, e.g. Quality of service and charging, for each application type.

4.1.3 Service Flows p. 6

Multi-purpose APN based Service Flow

In order to support the different characteristics of the different applications, the mobile service provider uses the bearer service attributes QCI and ARP. Flow based Charging (introduced in Release 6) or Policy Control and Charging (PCC) (introduced in Release 7) is used to provide the 3 applications with the right bearer service characteristics and priority as well as charging/billing in accordance with the SLA.

Multiple APN based Service Flow

In order to support the different characteristics of the different applications, the mobile service provider uses different APNs to distinguish the different applications:

An APN_CAR_DIAGNOSTIC APN is allocated for car diagnostic application to support frequent data connectivity;
A GOLD_APN is allocated for the anti-theft application to ensure the data connectivity fulfills the strict SLA;
An APN_CUSTOMER_CARE is allocated for customer care service to support a specific billing profile.

There is a need of simultaneously active IP stacks if and whenever multiple connections to different APNs are used. In the case where the MNO uses 3 different APNs as listed above it is required that the device has the capability to support 3 IP stacks and 3 IP addresses simultaneously.

4.1.4 Post-conditions p. 7

Each application uses distinct and different characteristics for communication.

4.1.5 Potential technical solutions p. 7

Three potential technical solutions based on the network features, Device Management or the UICC have been respectively identified.

4.1.5.1 UICC based solution p. 7

4.1.5.1.1 An enhanced ME and existing UICC based solution p. 7

In this solution, a list of APNs is stored in the UICC using the existing UICC file of EF_ACL (as specified in clause 4.2.48 of TS 31.102). The list of APNs is specifically ordered to link one specific APN to one specific application/service (e.g. first APN on the list is used for one specific application/service, second APN on the list is used for another specific application/service, etc).

Once acquired from the USIM on the UICC, the list of ordered APNs can be made available by the ME to applications that reside on the ME. Each ME application then informs the UE which APN to use to transport its data connection traffic, as per existing mechanisms.

In order to retain backwards compatibility for those HPLMNs that already use the existing EF_ACL field for its currently intended use (i.e. to control to which APNs a UE may attempt to establish a PDN Connection), it is proposed that the ME also performs the existing APN Control List mechanism. Therefore, in order to prevent a denial of service/PDN Connection activation failure, the HPLMN needs to ensure that all possible APNs that the ME may require (e.g. based on APNs provisioned in the HLRs'/HSS's subscription record for the UICC) are provisioned in the EF_ACL, including any well-known APNs that the ME does not usually need to have provisioned e.g. the IMS well-known APN.

The list of APNs in the UICC can be updated via existing SIM-OTA servers due to the reuse of the existing EF_ACL. Below are listed some possible solutions how a SIM-OTA server knows that the user of the UE has installed a new application and one or more APNs need to be configured for that application:

User-initiated application download #1 - For instance, the ME application designer can develop the application in a way to inform the user (or a platform) with an alert if the needed APN on the UICC is missing. This event can be used to trigger an OTA download mechanism to add the APN(s) into the UICC list.
User-initiated application download #2 - Before initiating the ME application download, an "eligibility check" is performed to verify whether the user has the corresponding APN in the UICC list. If the "eligibility check" is successful, then the ME application download starts. If the "eligibility check" fails, other solutions are possible e.g. to abort the transaction; to initiate an APN list OTA download on the UICC session; to inform the user.
MNO-initiated application download. Another solution is first to OTA download the APN list in the UICC, then to trigger the ME application download process only for those subscribers who have correctly completed the OTA download of the APN(s) in the UICC

4.1.5.1.2 An enhanced ME and enhanced UICC based solution p. 8

In this solution, a list of APNs (all the mandatory and optional fields) is stored in the UICC. This list contains some additional information to link one specific APN to one specific application (for instance, an optional description field can be allocated into the APN storage area of the UICC; then each application / each UICC issuer has the responsibility of the coding (a description text label, a digital encryption/signature based on shared keys, etc.).

The UICC may also contain some information to restrict the access to the list of APNs to specific applications. (note that the scope is for an UICC to prevent an un-authorized application on the ME to retrieve info dedicated to another application's APN, thus the restriction mechanism has an impact only on the UICC and not on the ME).

Each ME application retrieves the corresponding APN from the list in the UICC, then informs the UE which APN to use to route the application data connection traffic.

The list of APNs in the UICC can be updated OTA.

Below are listed some possible solutions how a SIM-OTA Server knows that the user of the UE has installed a new application and APN needs to be configured for that application:

User-initiated application download #1 - For instance, the ME application designer can develop the application in a way to inform the user (or a platform) with an alert in case the needed APN on the UICC is missing. This event can be used to trigger an OTA download mechanism to add the APN into the UICC list.
User-initiated application download #2 - Before initiating the ME application download, an "eligibility check" is performed to verify whether the user has the corresponding APN into the UICC list. If the "eligibility check" is OK, then the ME application download starts. If the "eligibility check" is NOK, other solutions are possible: to abort the transaction; to initiate an APN list OTA download on the UICC session; to inform the user; etc.
MNO-initiated application download. Another solution is first to OTA download the APN list in the UICC, then to trigger the ME application download process only for those subscribers who has correctly completed the OTA download of the APN in the UICC.

4.1.5.2 Device Management based solution p. 8

There is currently an existing mechanism to configure APNs for specific applications in the application profile configured on the device. Such a mechanism has been widely used for configuration of APNs for MMS, data (internet) traffic, email, etc. on feature phones as well as smart phones. OMA-CP and OMA-DM CONNMO protocols both support the ability to configure APNs per application profile. This current mechanism supports both the multi-purpose APN flow and the multiple APN flow described in clause 4.1.3.

While the capability to support APN configuration is not currently included in OMA Lightweight M2M (LWMM), the device management protocols specifically identified for constrained m2m devices, could also be enhanced to support APN configuration.

The following methods can be employed in performing APN configurations.

Client Initiated bootstrap: DM Client contacts the DM Server to retrieve the Bootstrap information [5]. OMA-DM R1.3 and above support this method.
Customized Bootstrap or factory bootstrap: Configuration is loaded in factory [5]. This is a combination of UICC based solution and Device Management based solution. Supported in OMA-DM R1.x, OMA-DM R2.0 and OMA-LWM2M R1.0.
Smart Card bootstrap: Bootstrap information (including APN configuration if needed) is applied to device configuration when the device is switched on [5]. A specific policy may disable that functionality in DM 1.x & DM2.0 further enabling other methods described in a) to take over further settings (including APN's). Both OMA-DM [5] and OMA-LWM2M [6] support this method.
Server Initiated bootstrap: When a new device is detected in the network, the core network informs the DM server of the new device address. DM Server receives the device address, then performs a Push mechanism to transfer the configuration information (including APN information) to the device. The DM Client only accepts Bootstrap Messages from an authorized DM Server [5].

4.1.5.3 Multi-purpose APN based solution p. 9

Solutions are provided based on existing features for Bearer Service QCI and ARP mechanism as well as Flow based Charging / Policy Control and Charging (PCC). When a UE requests a new PDN connection with a new APN it will receive a new IP address. The multi-purpose APN soultion is using a single IP adress and IP stack.

Table 1 shows the mechanisms available in 3GPP to satisfy the various objectives of this use case, in addition to the parameters required to be modified and a description of the mechanism.

Table 1: Single APN usage for multiple services

Objective	Mechanism	Parameters	Description
Frequent connections	None needed
Privacy & authentication	VPN	IPSec or SSL, Tunnel or transport, ACL.
High quality of service	QCI, ARP	QCI 1 to 3 = GBR bearer, high priority (e.g. 2), low packet loss rate (10-2 to 10-3), High ARP Priority Level (PL), PVI=0 to prevent pre-emption.	QCI Priority refers to priority in terms of resource allocation for a specific service i.e. in case where the UE is running concurrently VoIP (higher QCI priority) session and browsing WWW (lower QCI priority), the resources are assigned firstly to packets of VoIP and then to WWW (and e.g. if we don't have in the particular TTI resources to assign both packets, WWW need to wait and VoIP goes through). ARP priority refers to priority in terms of allocation of a service / bearer, i.e. if the eNB is highly loaded and a UE would like to setup VoIP (higher ARP priority) and WWW (lower ARP priority), the eNB would typically set only VoIP session, in order not to get overloaded. Or in other case if it is already overloaded it would kick off the bearers / services with lower ARP priorities.
Specific billing profile	Sponsored data connectivity	PCRF function provisioning

4.1.5.4 APN provisioning based on OMA DM bootstrap from UICC p. 9

APNs may be defined in an OMA DM Connectivity Management Object (ConnMO), as specified in [8] and [9], which is contained in the DM bootstrap file stored in the UICC. The ME reads the information from the UICC when a new UICC is detected, as specified in OMA DM Bootstrap specification [7].

The applications in the ME can then use the APN information (e.g. Identifier of the APN, Name parameter of the APN or other attributes of the APN) to select an APN from the DM Tree which has been loaded with APNs information read from the bootstrap file from UICC.

The UE is not required to connect to the OMA server to get further configuration.

The DM bootstrap file in the UICC (containing the ConnMO instance) can be updated via OTA as defined in TS 31.115 and TS 31.116.

4.2 In-vehicle User Equipment p. 10

4.2.1 Use Case Description p. 10

A smart in-vehicle user equipment provider offering connected devices without knowing in advance the mobile service provider that will be used by the automotive service provider.

4.2.2 Pre-conditions p. 10

The mobile service provider is not known by the automotive service provider.

4.2.3 Service Flows p. 10

The mobile service provider can be a Mobile Network Operator (MNO) or a Mobile Virtual Network Operator (MVNO). Data connectivity to be enabled is depending on which M(V)NO that is selected. The characteristics of the data connectivity is determined by subscriber profiles in HSS and PCC (or Flow based Charging) policies configured by the selected M(V)NO. Such subscriber information contain among other things default bearer characteristics and APN information.

One scenario for the automotive service provider is provided below:

at the manufacturing stage, a UICC is inserted into the in-vehicle UE. This UICC does not have an active USIM;
the M(V)NO is selected;
a USIM with the M(V)NO authentication credentials and profile is activated in the UICC;
the data connectivity is enabled using the selected mobile service provider, Bearer Service characteristics are set to the default bearer as described in subscriber information.

4.2.4 Post-conditions p. 10

The data connectivity is enabled using the selected mobile service provider in accordance with the subscription.

4.2.5 Potential technical solutions p. 10

4.2.5.1 UICC based solution p. 10

As per clause 4.1.5.1. The ME retrieves the APN to use from the UICC and uses this APN for the PDN connection.

4.2.5.2 Device Management based solution p. 10

This is a common scenario of device profile customization when a device is paired with a UICC. Once the device (IMEI) and UICC (IMSI) combination is detected, the device is automatically configured with application profiles (including APN information) specific to the operator. The behavior of automatic device detection (ADD) is specified by 3GPP. In practice there are several mechanisms possible to perform such device detection, e.g., HLR ADD notification [2], SS7 IMEI_CHECK and other similar SS7 message from MSC, or via an UICC applet initiated trigger.

The following methods can be employed in performing APN configurations.

Client Initiated bootstrap: DM client contacts the DM Server to retrieve the Bootstrap information [5]. OMA-DM R1.3 and above support this method.
Server Initiated bootstrap: When a new device is detected in the network, the core network informs the DM server of the new device address. DM Server receives the device address, then performs a Push mechanism to transfer the configuration information (including APN information) to the device. The DM Client only accepts Bootstrap Messages from an authorized DM Server [5].

4.2.5.3 Network based solution p. 11

As part of the authentication procedures when a MTC Device attaches to the VPLMN the authentication vectors and subscriber profiles are communicated from HSS to SGSN/MME. The subscriber profile includes a single APN (or a PDN subscription context marked as default with associated default APN [TS 23.060, clause A.1)). SGSN/MME is using this APN in the GTP signaling for PDN connection establishment towards the GGSN/PDN GW. This will work as long as the MTC Device is not sending an APN in the signaling to the SGSN/MME.

There is a standardized way to instruct the ME that all PDN connection requests shall exclude the APN in the signaling from a UE. The USIM file EF_ACL can be given the value "Network Provided APN" to instruct the ME to not send any APN since it is provided by the network.

The EF_ACL file with value "Network Provided APN" can be provisioned into the embedded UICC during manufacturing as part of the provisional subscription. This will ensure that always when the provisional subscription is used for connectivity to the Server the correct APNS is used.

The MTC service provider signs subscription contracts with selected MNOs for its MTC services. As part of those contracts the embedded UICCs of its MTC devices gets associated with IMSIs and subscriber profiles. The MNO prepare all operational subscriptions for the Server and subscriber profiles in the HSS including the APNMNO (associated with IMSI). The Server provisions the operational subscription of selected MNO into the embedded UICC of the MTC device. The operational subscription is enabled in the embedded UICC and taken into use by the MTC device.

When the embedded UICC of the MTC Device has been provisioned with the selected operational subscription profile, it contains also some basic settings of some EF files. The EF_ACL file is preferably set to "Network Provided APN" to use the default APN preferred by the selected MNO. This would guarantee that connectivity can be established with the selected MNO. This is preferably a general purpose APN for the MTC service used by the MTC Device as described in subclause 4.1.3 and subclause 4.1.5.3.

4.2.5.4 APN provisioning based on OMA DM bootstrap from UICC p. 11

In the use case of in-vehicle user equipment, the UICC contains a USIM application for each operator supported by the UICC. An APN is defined in a ConnMO, which is contained in the DM bootstrap file linked to each USIM application of the UICC.

Once a USIM is selected, the ME reads the APN information accordingly to OMA DM Bootstrap from UICC and use the APN information for data connection.

The UE is not required to connect to the OMA DM server to get further configuration.

4.3 Provision of an International M2M Service for a Business Customer p. 11

4.3.1 Use Case Description p. 11

A business customer needs a M2M type service that requires mobile devices to be deployed in multiple countries. The Mobile Network Operator (MNO) that will provide the M2M service does not have any operations in most of the countries involved.

4.3.2 Pre-conditions p. 12

The Mobile Network Operator (MNO) has procured eUICCs that all contain the same settings (the Operator's USIM profile) for use by all the devices on its network. The (U)SIM profile will also typically contain specific parameters e.g. details of the serving SMSC gateway to be used by the device.

A business customer of the MNO requires a M2M service and has procured devices that have specific settings for the MNO programmed into them by the device manufacturer. These settings include APN(s), SMS short-codes and voice short-codes.

For the M2M service, some of these devices will be deployed in countries where the MNO that supplies the M2M service does not have a network. It is not known at the time of procurement of the devices where they will be deployed.

Many of the MNOs in these foreign countries do not allow permanent roaming (because of regulatory or commercial reasons).

4.3.3 Service Flows p. 12

The MNO updates some of the M2M devices that are deployed in a foreign PLMN by "over the air" programming in order to avoid permanent roaming.

The eUICC is updated to use a new profile (subscription-swap). The devices now work using the foreign PLMN's eUICC profile.
The network specific settings are changed to ensure that the devices work properly on the new network. These include the APNs, SMSC Address, SMS Short-codes and Voice Short-codes.

4.3.4 Post-conditions p. 12

The devices now work correctly in the foreign network by using the new eUICC profile and the APNs, SMS Short-codes and Voice Short-codes relevant to that network.

4.3.5 Potential technical solutions p. 12

4.3.5.1 UICC based solution p. 12

Where profiles on a eUICC are managed remotely, the solution should allow provisioning of the correct APN(s) (e.g. using one of the solutions described in clause 4.1.4.1), and SMS numbers within the same (U)SIM (e.g. using the existing EF_SMSP, as specified in clause 4.2.27 of TS 31.102) that are appropriate to the chosen mobile network. The mechanism to do this should be part of or triggered by the process that manages the eUICC profile so that all parameters relating to the provisioning or swapping of the mobile network can be updated at the same time. Such an update mechanism is not currently available in 3GPP specifications.

4.3.5.2 Device Management based solution p. 12

This scenario is similar to the existing UICC swap scenario for mobile devices [3]. Once the subscription swap has happened in the eUICC, a new combination of device identity (IMEI) and subscription (IMSI) is identified which can then be used to modify the application profiles on the device (including the APNs) as per the new MNO requirement.

The following methods can be employed in performing APN configurations.

Client Initiated bootstrap: DM Client contacts the DM Server to retrieve the Bootstrap information [5]. OMA-DM R1.3 and above support this method.
Customized Bootstrap or factory bootstrap: Configuration is loaded in factory [5]. This is a combination of UICC based solution and Device Management based solution. Supported in OMA-DM R1.x, OMA-DM R2.0 and OMA-LWM2M R1.0
Smart Card bootstrap: Bootstrap information (including APN configuration if needed) is applied to device configuration when the device is switched on [5]. A specific policy may disable that functionality in DM 1.x & DM2.0 further enabling other methods described in a) to take over further settings (including APN's). Both OMA-DM [5] and OMA-LWM2M [6] support this method.
Server Initiated bootstrap: When a new device is detected in the network, the core network informs the DM server of the new device address. DM Server receives the device address, then performs a Push mechanism to transfer the configuration information (including APN information) to the device. The DM Client only accepts Bootstrap Messages from an authorized DM Server [5].

4.3.5.3 Network based solution p. 13

The eUICC remote provisioning for the subscription swap is triggered by sending an SMS to the embedded UICC. This SMS triggers the embedded UICC to request a PDN connection using a pre-provisioned APNS. The ME requests PDN connectivity by signaling to SGSN/MME which includes the APNS to be used. It should be noted that this APN is associated with a management application on the embedded UICC operational profile.

When the PDN connection with APNS has been established the new operational USIM subscription profile is provisioned by the Server to the embedded UICC. The MTC Device is triggered to restart (power off and on) to start using the new subscription profile and after restart to register with the new MNOs network.

The new operational USIM subscription profile contains also some settings of some EF files. The EF_ACL file is preferably set to "Network Provided APN" to use the default APN preferred by the new MNO. This would guarantee that connectivity can be established with the new MNO. This is a general purpose APN for the MTC service used by the MTC Device as described in subclause 4.1.3 and subclause 4.1.5.3. However, if other usage of APN is preferred for Applications running in the ME then normal use of MNO SIM-OTA configurations of the operational subscription can be done to update the EF_ACL file with a white list of APN(s) and automatic device configuration as described in subclause 4.2.5.2 can be used for further ME configurations.

The embedded UICC was at manufacture time pre-configured with a provisional subscription which is used for providing initial connectivity to a Server for the purpose of provisioning a new operational subscription (selected MNO) into the embedded UICC. The provisional subscription is kept as a fallback in case no operational subscription is enabled to provide connectivity.

4.3.5.4 APN provisioning based on OMA DM bootstrap from eUICC p. 13

This Business Customer scenario is similar to an existing UICC swap.

The downloaded eUICC profile contains an OMA DM bootstrap file that contains APN information defined in a ConnMO.

Once the eUICC profile is enabled, the ME reads the information from the eUICC profile including the APN information accordingly to OMA DM Bootstrap from UICC,

The ME uses the APN information for data connection.

The UE is not required to connect to the OMA DM server to get further configuration.