The scope of this document is to shed some light on the effects of the various settings in MMI that can block access to services to subscribers.
Controlling access to services via SIM settings of subscriber
MMI Menu: Subscriber Management → SIMs → (choose SIM) → CS active/ PS active / LTE active checkboxes
These are checkboxes that control what services a subscriber is allowed to access.
CS Active controls access to CS Services (calls, SMS, USSD).
Setting CS Active to false will have the following effects:
- a register attempt from that IMSI for CS services will be denied by YateHSS with reason unknownSubscriber at authentication step.
- for a subscriber that was already registered in the network: a CancelLocation with subscriptionWithdraw is sent to UE. This means that the subscriber is kicked out of the network for CS services because it is not allowed any kind CS service anymore.
PS Active controls access to data services via 2G/3G. LTE Active controls access to data services via 4G.
Setting any of these fields to false will trigger the HSS :
- to reject authentication for data services on 2G/3G (if PS Active is false) and/or 4G (if LTE Active is false) for that IMSI
- to send a CancelLocation with subscriptionWithdraw if the IMSI is registered on the technology for which active was set to false.
These settings can also be controlled via this API request:
JSON:
{
“request”: “set_sim”,
“params”: {
“imsi”: “001010000000008”,
“iccid”: “12121212121212121212”,
“extra_id”: “sub_11”,
“sim_id”: “1”,
“cs_active”: false,
“ps_active”: true,
“lte_active”: true
}
}
At least one of the italic fields must be present in order to identify the SIM for which you want to run the API request.
The CS active/PS Active/LTE active setting from MMI Menu: Profile Management -> SIM Profile -> (choose profile) -> CS/PS/LTE (checkbox) control the initial value CS/PS/EPS active settings from the SIM. So all SIMs created using a SIM profile will inherit its active settings. After the SIM has been created, the CS/PS/EPS active settings can be altered via set_sim API request or via MMI Subscriber Management → SIMs → (choose SIM) → CS active/ PS active / LTE active checkboxes.
Controlling access to services using ODB (Operator Determined Barring)
MMI Menu: Subscriber Management → Subscribers → (choose subscriber) → ODB – Operator determined barring
The checkboxes from this section allow configuring which services the network should reject to provide to this specific subscriber.
Each ODB type has the following meaning:
| ODB - Operator determined barring | |
|---|---|
| ROAM | This bars incoming and outgoing calls and incoming SMSs when subscriber is in roaming. |
| BAOC | This bars all outgoing calls, regardless of the fact the subscriber is in roaming or not. Subscriber can still use other CS services (USSD, SMS, receive incoming calls) |
| BOIC | Barring of all international outgoing calls. VLR will bar outgoing calls to international numbers. Subscriber can still use other CS services (USSD, SMS, receive incoming calls) |
| BoicExHC | Barring of all international outgoing calls except those directed to the Home PLMN country. VLR will bar outgoing calls to international numbers that are not from the same range as the HPLMN. Subscriber can still use other CS services (USSD, SMS, calls to HPLMN numbers, incoming calls) |
| BAIC | This bars all incoming calls and SMSs, regardless of the fact the subscriber is in roaming or not. Subscriber can still use other CS services (USSD, outgoing SMS, outgoing calls) |
| BicRoam | Barring of all incoming calls and SMS when roaming outside the HPLMN country. Subscriber can still use other CS services (USSD, outgoing SMS, outgoing calls) |
| BcfExHC | Barring of Call Forward numbers Except Home Country. This forbids setting a Forwarding number to a number that isn’t in the home country of the network. All other CS services are available (calls, SMS, USSD). This is not a barring defined by the ETSI standards, but specific to YateHSS. |
| PS | This bars all access to PS services from MME/SGSN. In 4G, this will lead to failure in the registration procedure, so CS/IMS services are also rejected. In 2G/3G, the subscriber would still have access to CS services. |
| PsRoam | Barring access to PS services when roaming in other networks. It has the same behaviour as PS ODB, but it only applies when the subscribers is in roaming. This is not a barring defined by the ETSI standards, but specific to YateHSS. |
| HplmnAP | This bars access to data services provided by a HPLM AP when the subscriber is in roaming |
| VplmnAP | This bars access to data services provided by a VPLMN AP when the subscriber is in roaming. |
Changing barrings while the subscriber is registered will lead to the HSS sending a CancelLocation.
These settings can also be controlled via this API request:
JSON:
{
“request”:”set_subscriber”,
“params”: {
“subscriber_id”: “1”,
“msisdn”: “882801001”,
“extra_id”:“sub_11”,
“sim”: {
“sim_id”:”1″,
“imsi”: “001010000000008”,
“iccid”: “12121212121212121212”
},
“odb”: {
“roam”: false,
“baoc”: false,
“boicExHC”: false,
“baic”: false,
“boic”: false,
“bicRoam”: false,
“bcfExHC”: false,
“ps”: false,
“psRoam”: false,
“hplmnAP”: false,
“vplmnAP”: false
}
}
At least one of the italic fields must be present in order to identify the subscriber for which you want to run the API request.
Controlling access to services using Profile ODB settings
MMI Menu: Profile Management -> CS Profile/ PS Profile / EPS Profile -> (choose profile) -> ODB – Operator determined barring
These have the same meaning as the ODB settings from above. But, instead of being applied to a single subscriber, these apply to all subscribers that use this profile.
For one ODB type setting, if the value from the profile currently in use or the one in the specific subscriber is true, then that ODB will be applied for the subscriber.
E.g. for a subscriber that has no ODB PS set, but has:
- EPS profile with ODB PS set to true and PS profile with ODB PS set to false, subscriber is registered in 2G => ODB PS value is false (no barring) because PS profile is use
- EPS profile with ODB PS set to true and PS profile with ODB PS set to false, subscriber attempts registration in 4G => ODB PS value is true (access is barred) because EPS profile is in use.
These settings can also be controlled via this API request:
For CS:
JSON:
{
“request”:”set_cs_profile”,
“params”: {
“name”: “Postpaid Regular”,
“cs_profile_id”: 1,
“odb”: {
“roam”: false,
“baoc”: false,
“boic”: false,
“boicExHC”: false,
“baic”: false,
“bicRoam”: false,
“bcfExHC”: false
}
}
}
For PS: JSON:
{
“request”:”set_ps_profile”,
“params”: {
“ps_profile_id”: 1,
“name”: “Prepaid data”,
“odb”: {
“ps”: false,
“psRoam”: false,
“hplmnAP”: false,
“vplmnAP”: false
}
}
}
For EPS: JSON:
{
“request”:”set_eps_profile”,
“params”: {
“eps_profile_id”: 1,
“name”: “Postpaid data”,
“odb”: {
“ps”: false,
“psRoam”: false,
“hplmnAP”: false,
“vplmnAP”: false
}
}
}
At least one of the italic fields must be present in order to identify the profile for which you want to run the API request.
Controlling access to services via Teleservices
MMI Menu: Profile Management -> CS Profile -> (choose profile) -> Teleservices
MMI Menu: Profile Management -> PS Profile -> (choose profile) -> Teleservices
This specifies which teleservices are provisioned for the subscribers that have this CS / PS profile.
YateHSS support refusing routing for MT SMSs for a subscriber that hasn’t “shortMessageMT-PP” / allTeleservices /allShortMessageServices teleservices provisioned in CS profile. YateHSS will send in InsertSubscriberData the provisioned teleservices.
YateUCN does not handle teleservices.
These settings can also be controlled via these API requests:
JSON:
{
“request”:”set_cs_profile”,
“params”: {
“name”: “Postpaid Regular”,
“cs_profile_id”: 1,
“teleservices”: [
“telephony”,
“shortMessageMO-PP”,
“emergencyCalls”,
“shortMessageMT-PP”
]
}
}
JSON:
{
“request”:”set_ps_profile”,
“params”: {
“ps_profile_id”: 1,
“name”: “Prepaid data”,
“teleservices”: [
“shortMessageMT-PP”,
“shortMessageMO-PP”
]
}
}
At least one of the italic fields must be present in order to identify the profile for which you want to run the API request.