Nokia SBC Training - LLD Part 2 - Data Design (PDF)

Nokia SBC Training LLD Part 2 – Data Design David Hong NPI, Service Delivery Platforms Applications & Analytics July 2017 Version 1.0 1 © Nokia 2017 Confidential Disclaimer This training module covers only the “BASIC” SBC configuration data that one needs to configure for a Nokia iSBC...

Nokia SBC Training LLD Part 2 – Data Design David Hong NPI, Service Delivery Platforms Applications & Analytics July 2017 Version 1.0 1 © Nokia 2017 Confidential Disclaimer This training module covers only the “BASIC” SBC configuration data that one needs to configure for a Nokia iSBC. The configuration data mentioned in this training module does not cover all the parameters and it is expected that customer LLD may need to further customize other data for a customer site. It is assumed that one can reference configuration data provided in sample DIF so this training will simply make a reference to sample DIF without providing more details. The training material used in this training should only be used as a reference. One should not use any of the data in this training as a Blueprint for a customer site. The configuration data covered in this training will be described based on functional areas; that is, Global Data, CFED, DFED, AFED, PFED, P-CSCF, IBCF, PD-FE, CRF, BGC, BGW (SCM/PIM/MCM). For Access Only tables and Peering Only tables, they will be marked with “Access” and “Peering” respectively. If not specifically mentioned, they are applicable to both Access and Peering. 2 © 2017 Nokia Integrated SBC Access + Peering Software Architecture Peering Network 1 OAM PFED KPFED Peering IMS Service – P-iSGW Network 2 SC IBCF(ALG,CRF), PD-FE IMS Core PCSCF(ALG),PD-FE PFW CFED Peering IMS Service – IBCF(ALG,CRF), PD-FE Network n PCSCF(ALG),PD-FE Other Trusted QFED AFED KFEPH Network Access A-iSGW Network DFED iCCF BGC ENUM/DNS FW SC: Session Controller FW: Firewall Server PFED: Peering Front End Distributor SIP CFED: Core Front End Distributor Media DNS/ENUM DFED: Diameter Front End CCF SCM Diameter Distributor Plane BGC: Border Gateway Controller H.248 iCCF: Internal CCF PIM MCM QFED: Query FED 3 © 2017 Nokia SBC Interfaces 4 © 2017 Nokia Tips – How to Search for Parameters In addition to using SBC documentation (e.g., provisioning guide) as a reference, one can search keywords in DIF SP worksheet. 5 © 2017 Nokia Tips – How to Search for Parameters – Cont’d Another method of performing search is to search keywords in YANG data model on a YANG Tool server. 1. Go to YANG Tool server (e.g., [email protected] password: 123456) 2. Change directory to /home/yact/YANG_ims/yang/specifications 3. For SBC Signaling, search under SBC-signaling/Rx.x.x 4. For RMS Media, search under SBC-media/Rx.x.x 5. For OpenStack/VMware Media, search under 7510-CE/ Here is an example of finding “Topology” related parameters in YANG data model. 6 © 2017 Nokia SBC Global Data 7 © 2017 Nokia Nokia Internal Use Signaling Network Parameters in DIF – Basic Information The following data must be configured properly in NP tab of a DIF. Other NP/DP parameters will be covered in part 3 of this training. Deploy Type: must be set to CBAM for OpenStack and OLV for RMS/VMware System Name: used in OAM WebUI and PM Reports System Prefix: used as hostname prefix for both Signaling and RMS Media VMs License Reference Name String: this string is provided by license generation folks and is also used to generate SBC license along with System Prefix, network information, etc. Time Zone: update per time zone used by the customer Local DNS Domain: a.k.a local zone which is used to construct FQDN of internal component. For example, pdfe-stdn. ParameterName Allowed Values NE_Columns_Start ne-xxx NE_Columns_End VMInformation sbc01-oam-a, sbc01-oam-b, sbc01-fw-a, > VMInformation > VMInformation Record Realm 4 trustedRealm2 >> CoreBearerRealmTable 19 © 2017 Nokia  Published Realm One can defined multiple Published Bearer Realms which are sent from BGC to BGW in H248 to select Access RTP IP/port. Therefore, name for Published Realms defined in Signaling and Media must match exactly. For signaling, define Published Realms in PublishedRealmTable. For RMS/VMware, access VLAN IDs are specified in Published Realm table under SIGNALING_V4_VLAN/SIGNALING_V6_VLAN One needs to associate a Published Realm with a Core Realm in CORE_PRIMARY_BEARER_REALM_ID/CORE_ALTERNATE_BEARER_REALM_ID For media, define Published Realm in “System Realm Parameters”. The screenshot provided below purposely have different names for signaling and media which is incorrect. > Record > Record >> PublishedRealmTable 20 © 2017 Nokia SBC I-CSCF Selection Data – Access Only 21 © 2017 Nokia Nokia Internal Use P-NAPTR Configuration on SBC  SBC provides P-NAPTR (Pseudo NAPTR) capability that consists of P-NAPTR Region Table and P-NAPTR Target URI which provides NAPTR/SRV functions to SBC locally.  P-NAPTR Target URI is referenced by P-NAPTR Region Table and should be configured first  The following example shows P-NAPTR configuration that maps “example.com” to “icsf- stdn.isc1.imslab.com” and “icsf-stdn.isc2.imslab.com” with 70% of traffic routed to isc1 and 30% of traffic routed to isc2. 22 © 2017 Nokia I-CSCF Selection I-CSCF can be specified in “Home I-CSCF” in SBC’s NGSS Parameters or one can leave “Home I-CSCF” empty and map subscriber home domain in P-NAPTR to I-CSCF list.  P-NAPTR table is looked up first (see example below), if no entry found then  SRV query (_sip._udp. or _sip._tcp.) is launched, if no entry found then  A-record query on is launched 23 © 2017 Nokia  Signaling PNAPTR Target URI Table Create records for all I-CSCFs (specified in TARGET_URI) that SBC can use to select I-CSCF Record >> PNAPTRTargetURITable 24 © 2017 Nokia  Signaling PNAPTR Region Table REGION_FQDN should be set to Subscriber Home Domain from CIQ For each PNAPTR Record, one needs to think of order, preference, and weight Order: 10 for local and 20 for remote Preference can be 10, 20 or 30. Lower preference number has higher priority Weight is used to determine priority if order and preference are the same > Record >> PNAPTRRegionTable 25 © 2017 Nokia  Signaling Home Domain Table Use this table to specify mapping of home domain to PNAPTR Region ID Record >> HomeDomainTable 26 © 2017 Nokia SBC CFED Data 27 © 2017 Nokia Nokia Internal Use  Signaling CFED Service Table Specify CFED IPv4/IPv6 IP in CFED Service Table Create additional record if CFED is connected to multiple SIG Core networks. v6PublishedExternalFloatingIPAddresses SUPPORT_NK_MODE No SUPPORT_TAS_NK_MODE No SPARE_ID 0 >> Record >> CFEDServiceTable 28 © 2017 Nokia  Signaling CFED Port Table Set APPLICATION_TYPE to pcsf or ibcf depending on whether it is access or peering. For access and peering combined, create two CFED ports with one port for pcsf and one for ibcf. Application Group is not application for Application Type PCSF and you need to specify one for IBCF (e.g., stdn) EXTERNAL_HOST_NAME will be used by CFED to send SIP messages to IMS Core or Trusted Network. The FQDN must be resolvable by external DNS server and should not contain iSBC Local Zone For access and peering combined, you will need to assign different external/internal port number for PCSF and IBCF Configure CFED IPv4/IPv6 IP in PUBLISHED_V4/6_EXTERNA_FLOATING_IP_ADDRESS If CFED supports secondary SIG Core network, configure SECONDARY_PUBLISHED_V4/6_EXTERNAL_FLOATING_IP_ADDRESS Record >> Record >> CFEDPortTable >> CFEDPortTable 29 © 2017 Nokia SBC Diameter Data 30 © 2017 Nokia Nokia Internal Use  Signaling DFED Server Table DFED Server Table needs to be created but if you customize from sample DIF, then there is no need to customize DFED Server Table. Record >> DFEDServerTable 31 © 2017 Nokia  Signaling Multiple Destination Profile Table (SCTP Multi-Homing Only) If Diameter over SCTP with Multi-Homing is Record > Record >> DiameterMultipleDestinationsProfileTable 32 © 2017 Nokia  Signaling Diameter Profile Table for DFED > Record DiameterConnectionInterface If Multi-Homing is used, then Record 33 © 2017 Nokia  Signaling DFED Port Table Create a DFED port for each diameter application; for example, Rf and Rx. Record DFED and should be unique within a DFED > Record >> DFEDPortTable 34 © 2017 Nokia  Signaling Diameter Profile Table for DiameterConnectionInterface For iCCF, one should use internal CCF Service > DiameterConnectionInterface For Rf going through DFED, set > DiameterConnectionInterface > DiameterConnectionInterface DiameterConnectionInterface >> Record  Record used, the 2nd SC VM will contain IMS service/pool > Record > Record > Record > Record > Record >> ServiceToDiameterTable 36 © 2017 Nokia SBC PFED Data 37 © 2017 Nokia Nokia Internal Use  Signaling PFED Service Table (Peering Only) Specify CFED IPv4/IPv6 IP in PFED Service Table Create additional record if PFED is connected to multiple Peering networks Set DSCP value to be used for SIP if specific DSCP value is requested by the customer Record >> PFEDServiceTable 38 © 2017 Nokia  Signaling PFED Port Table (Peering Only) Set PORT_NAME to a unique name within the same PFED Service EXTERNAL_HOST_NAME will be used by PFED to send SIP messages to Untrusted Peering networks. The FQDN must be resolvable by external DNS server and should not contain iSBC Local Zone For access and peering combined, you will need to assign different external/internal port number for PCSF and IBCF Configure PFED IPv4/IPv6 IP in PUBLISHED_V4/6_EXTERNA_FLOATING_IP_ADDRESS Configure IPV4/IPV6_VLAN_ID if VLAN is used Record >> PFEDPortTable 39 © 2017 Nokia SBC Firewall Data 40 © 2017 Nokia Nokia Internal Use Signaling Firewall Policy Tables 41 © 2017 Nokia  Signaling Firewall Policy Tables – Cont’d If you don’t need to customize signaling firewall policy tables, you may copy the following tables from Sample Signaling DIF: FephFlowPolicyTable FephAggPacketPolicyTable FephAggFlowPolicyTable (Access Only) FephRemoteIpPolicyTable (Access Only) SipTrustedRateLimitSet (Access Only) SipUntrustedRateLimitSet (Access Only) SipAggregateTrustedRateLimitSet SipAggregateUntrustedRateLimitSet (Access Only) SourceAddressPolicy (Access Only) AggregateSourceAddressPolicy SecurityGatewayProfile (Access Only) PeeringiSGWProfileTable (Peering Only) 42 © 2017 Nokia SBC PDFE Data 43 © 2017 Nokia Nokia Internal Use  Signaling SBLP Profile Table (Access Only) There are many configurable parameters in SBLP Profile table which controls many features supported by SBC. This training material only list those parameters you must consider changing in order to have a working SBC if you use a sample Access DIF. DAIMETER_INTERFACE_TYPE must be set accordingly. If you are working with VoLTE with ATCF/ATGW, it is likely that TISPAN/3GPP is used. If you are working with non-VoLTE, then TISPAN might be set. FQDN_TISPAN should be set to pdfe-stdn. If BGW support transcoding, then set MEDIA_NEGOTIATION_SUPPORT to Yes FQDN_3GPP should be set to PCRF FQDN/IP > NPLI_OPTIONS >> Record >> SblpProfileTable 44 © 2017 Nokia  Signaling IBCF SBLP Profile Table Similar to SBLP Profile Table, this training only mentions the following items that you should consider but depending on other features used, other parameter settings should be considered as well (e.g., PEM Header). Whether to set early media support parameters to Yes or not (e.g., PEERING_INGRESS/EGRESS_UPLINK_ENABLED, PEERING_INGRESS/EGRESS_DOWNLINK_ENABLED). Set MEDIA_NEGOTIATION_SUPPORT to Yes if transcoding support is needed PDFProfileTable 49 © 2017 Nokia  Signaling Diameter Port Table For each IMS Service (P-CSCF/IBCF), you may want to create a PDFE instance with diameter port name pdfe-stdn and port number 3868 in DiamPort table. For example, if you have 2 SC VM pairs, then there are 8 IMS services and you can associate PDFE diameter port for node 320 through 327. Record >> DiamPort Record >> DiamPort 50 © 2017 Nokia SBC P-CSCF Data (Access Only) 51 © 2017 Nokia Nokia Internal Use  Signaling Common P-CSCF Profile Table If you use Access Sample DIF, you can copy CommonPcscfProfileTable from the sample DIF. Record >> CommonPcscfProfileTable 52 © 2017 Nokia  Signaling STN-SR Table (Access Only – VoLTE) Populate STNSRTable entries based on STN-SR data provided by customer. Each STN-SR later Record used in a Registration scenario > Record > Record > Record >> STNSRTable 53 © 2017 Nokia Network Architecture from 3GPP TS 23.002, Figure 6e IMS Service Centralization and Continuity Reference Architecture when using ATCF enhancements UE 54 © 2017 Nokia  Third party register – Enhanced SRVCC (eSRVCC) UE P-CSCF ATCF I-CSCF S-CSCF SCG HSS MME (M1) REGISTER (M2) REGISTER ATCF decides to insert itself. ATCF adds a Path header with its URI and STN-SR (M3) REGISTER (Path: the g.3gpp.atcf-psi media feature tag containing the ATCF PSI and g.3gpp.atcf media feature tag containing the STN) Select S-CSCF (M4) REGISTER (Path: the g.3gpp.atcf-psi media feature tag containing the ATCF PSI and g.3gpp.atcf media feature tag containing the STN) Authentication check (M5) 401 Unauthorized (M6) 401 Unauthorized (M7) 401 Unauthorized (M8) 401 Unauthorized (M9) REGISTER (M10) REGISTER ATCF decides to insert itself. ATCF adds a Path header with its URI and STN-SR (M11) REGISTER (Path: the g.3gpp.atcf-psi media feature tag containing the ATCF PSI and g.3gpp.atcf media feature tag containing the STN) (M12) REGISTER (Path: the g.3gpp.atcf-psi media feature tag containing the ATCF PSI and g.3gpp.atcf media feature tag containing the STN) Profile download (M13) 200 OK (REGISTER) (M14) 200 OK (REGISTER) (M15) 200 OK (REGISTER) (M16) 200 OK (REGISTER) S-CSCF sends third party REGISTERs to AS (M17) REGISTER (BODY with 200 OK (REGISTER) Path: the g.3gpp.atcf-psi media feature tag containing the ATCF PSI and g.3gpp.atcf media feature tag containing the STN) 55 © 2017 Nokia  Third party register – Enhanced SRVCC (eSRVCC) UE P-CSCF ATCF I-CSCF S-CSCF SCG HSS MME SCG updates the UE’s status in local registration data If eSRVCC active, look for STN-SR in g.3gpp.atcf.media tag. If none, SCG uses its own STN-SR. For new registration and when the STN-SR for the UE has changed, SCG writes STN-SR. Note there is no sequence number needed to write STN-SR. Add NOTE on procedure (M18) Sh Profile-Update-Request (PUR) ((User-Identity = MSISDN, Data-Reference = STN-SR (27), Service-Data =new STN-SR, Origin-Host = SCG Diameter name) (M19) Sh Profile-Update-Answer (PUA) (Result-Code) SCG saves current STN-SR for the user in local registration data (to be able to detect in later re-registrations if the STN-SR needs to be updated). SCG informs ATCF of ATU-STI (M20) MESSAGE (Request-URI: ATCF PSI from Path header of REGISTER, P-Asserted-Id: SCG URI, Body: the application/vnd.3gpp.SRVCC-info+xml MIME body containing C-MSISDN and ATU-STI of SCG) (M21) 200 OK (MESSAGE) ATU-STI: Access Transfer Update – Session Transfer Identifier 56 © 2017 Nokia  Signaling P-CSCF Profile Record by the P-CSCF >> PcscfProfileTable If Emergency is not provided by P-CSCF, set EMERGENCYHOSTURI, RUIRTOEMERGHOST to n/a; If Topology Hiding feature is enabled, set otherwise, customize the parameters based on site data SIP_TOPOLOGY_HIDING to Yes If external DNS is not set up to resolve P-CSCF FQDN, If ATCF is used for VoLTE, set SUPPORT_ATCF to Yes then set PROVIDE_PCSCF_IP_TO_UE to Yes 57 © 2017 Nokia Network Indicator  P-CSCF will include P-Visited-Network-ID header with Network Indicator from P-CSCF profile  Each subscriber can be assigned with authorized Visited Network ID that the subscriber can visit. If the subscriber tries to registers with a different Network ID, HSS will consider it is roaming and may not be allowed.  Each subscriber can also be assigned with restricted Visited Network ID that the subscriber is not allowed to visit. 58 © 2017 Nokia SBC SC Data 59 © 2017 Nokia Nokia Internal Use  Signaling IMS Device Server Table For each IMS service, there should be a corresponding DNSConfiguration HostSuffixInformation > PoolInformation Vmpair name defined in NP worksheet. For SERVICELABEL n/a >> ComponentParameters example, SC VM pair 2 might be sc2-a,sc2-b >> FixedInternalIPAddress ADMINSTATE n/a POOL_ID should be unique. SC VM pair 1 will use >> DeviceServerConfiguration pool ID 0-3, SC VM pair 2 will use pool ID 4-7 and >> DeviceServerStatusCheckConfiguration so forth >> IMSDeviceServer 60 © 2017 Nokia  Signaling Feph Aggregate Policy Assign Table (Access Only) For each IMS service, there should be a > Record the # of IMS services that match your iSBC > Record IMS pool 0; that is, 65-72 for IMS pool 0-7 > Record >> Record >> Record >> FephAggPolicyAssignTable 61 © 2017 Nokia  Signaling Tcp Connections Table For each IMS service, there should be a Record Set IMS_POOL_ID, IMS_NODE_ID accordingly > Record 62 © 2017 Nokia  Signaling FEPH Enabled Services Table (Access Only) > Record > CANDIDATES_FOR_FEPH_ENABLED_IMS_SERVICES FEPH_ENABLED_ENTRY Set FEPH_ENABLED_SERVICE_INSTANCE > FEPH_ENABLED_ENTRY > FEPH_ENABLED_ENTRY > FEPH_ENABLED_ENTRY >> FEPH_ENABLED_IMS_SERVICES >> Record >> FephEnabledServicesTable 63 © 2017 Nokia  Signaling FEPH IPsec Parameters Table (Access Only) SERVICE_ENTRY > SERVICE_ENTRY > SERVICE_ENTRY >> Record >> FephIpsecParametersTable 64 © 2017 Nokia  Signaling NGSSSIPia Tables Record 5061 for IBCF) Record parameters should be set to “No v4” or “No v6” >> NGSSSIPia 65 © 2017 Nokia SBC BGC/BGW Data 66 © 2017 Nokia Nokia Internal Use  Signaling H248DSVariant and H248GWVariant Tables You may copy H248DSVariant and H248GWVariant from sample DIF Parameter 29 (IPDC Support) must be set to Y in H248GWVariant If you enable media inactivity detection, Set Parameter 32 “Application data inactivity detection” to Y Other H.248 GW Variant setting consideration is listed in the table below ParameterValue >> Record ParameterValue >> Record 67 © 2017 Nokia  Signaling H248 Device Server Table You may copy H248DeviceServer from sample DIF but make sure that PRIMARY/SECONDARY_HOST_SUFFIX matches VMpair specified in NP worksheet GatewayH248 69 © 2017 Nokia Media VMG Table VMG data in user-input file should match those defined in Signaling DIF. VMG VMG Type VMG ID MG Port MGC Primary IP MGC Secondary IP MGC Primary PORT MGC Secondary PORT IPv4 VMG 1 5001 192.168.172.32 192.168.172.33 2944 2944 IPv4 VMG 2 5002 192.168.173.32 192.168.173.33 2944 2944 IPv4 VMG 3 5003 192.168.174.32 192.168.174.33 2944 2944 IPv4 VMG 4 5004 192.168.175.32 192.168.175.33 2944 2944 IPv4 VMG n/a n/a n/a n/a n/a n/a 70 © 2017 Nokia Signaling Border Gateway Published Realm Table For each Border Gateway defined in Signaling, one needs to associate a published realm with the gateway > Record >> BorderGatewayPublishedRealmTable 71 © 2017 Nokia SBC IBCF Data 72 © 2017 Nokia Nokia Internal Use Signaling IBCF Related Tables IBCF Related Tables: IbcfSipProfileTable IbcfVirtualNetworkTable PeeringSDPProfileTable (covered earlier) IbcfSBLPProfileTable (covered earlier) IbcfTrunkGroupTable IbcfIngressTrunkGroupMapping IbcfProfileTable 73 © 2017 Nokia Signaling IBCF SIP Profile Table One can copy IbcfSipProfileTable from sample DIF which uses default settings. Record >> IbcfSipProfileTable 74 © 2017 Nokia IBCF Virtual Network and Trunk Group IBCF Trunk Group (TG): Stands for a remote connecting node or a group of remote connecting nodes belonging to one FQDN. Most IBCF related configurations are provisioned at Trunk Group level. IBCF Virtual Network (VN): Dependent on the Virtual Network Type (core or peer), stands for a core or peering network connected with the peering SBC. One Virtual Network can contain one or multiple IBCF Trunk Groups. CAC policy can be assigned at Virtual Network level, and iSGW profile (used for SIP message rate limitation) can be assigned to peer side Virtual Network (i.e. peering Network). Each IBCF call has one ingress Trunk Group and one egress Trunk Group. The ingress Trunk Group is identified based on incoming initial request’s Via header IP, port and transport, and optionally RFC4904 TGRP/Trunk-Context parameters in Contact or R-URI; The egress Trunk Group is identified via CRF routing. VN 1 TG 1 Connecting Node 1 Scenario 1: The TG’s destination is Core or an IP address, so each TG identifies TG 2 Connecting Node 2 Peer a remote connecting node. TG n Network Connecting Node n Peering SBC VN 2 Scenario 2: The TG’s destination is a Connecting Node 1 TG 1 Core or FQDN, so one TG identifies a group of remote connecting nodes sharing Connecting Node 2 Peer the FQDN. Connecting Node n Network 75 © 2017 Nokia Signaling IBCF Virtual Network Table Record For Peering VN, PFED_PORT must be specified > Record >> IbcfVirtualNetworkTable 76 © 2017 Nokia Signaling IBCF Trunk Group Table Next, one should create IBCF trunk groups per Virtual Network TG_ID should be unique within the same Virtual Network CRF_ROUTEINE_PROFILE_ID can be set to a CRF Route Profile ID instead of setting it to 0 then update it with a CRF Route Profile ID (this requires a later version of YANG tool) IBCF_SIP_PROFILE_ID, IBCF_SDP_PROFILE_ID, and IBCF_SBLP_PROFILE_ID should be set accordingly > REMOTEIPADDRESSList EGRESS_CRF_TASK_ID 0 CRF_ROUTINE_PROFILE_ID 1 SERVICE_LEVEL_POLICY_ID 0 EGRESS_CRF_TASK_ID 0 IBCF_SIP_PROFILE_ID 1 SERVICE_LEVEL_POLICY_ID 0 IBCF_SDP_PROFILE_ID 1 IBCF_SIP_PROFILE_ID 1 IBCF_SBLP_PROFILE_ID 1 IBCF_SDP_PROFILE_ID 1 >> Record IBCF_SBLP_PROFILE_ID 1 >> Record 77 © 2017 Nokia Signaling IBCF Ingress Trunk Group Mapping Table For each IBCF Core Trunk Group, one needs to define the same TG information in IbcfIngressTrunkGroupMappingTable to allow IBCF to map IP/Port or RFC4904 TGRP/Trunk Context to an IBCF core side TG. To use RFC4904_TGRP/RFC4904_TRUNK_CONTEXT, one must set INGRESS_IBCF_TG_MAPPING_KEY in NGSS Parameters to an appropriate value other than “none”. Record >> IbcfIngressTrunkGroupMappingTable 78 © 2017 Nokia Signaling IBCF ProfileTable One can copy IBCF Profile from sample DIF > Record >> IbcfProfileTable 79 © 2017 Nokia SBC CRF Data for Peering 80 © 2017 Nokia Nokia Internal Use Centralized Routing Function - Basic Routing Flow No Match Routing Profile with Found or controls and indexes failed task to routing tables Routing No match found or failed Task Tables Route Plan Special Priority List Treatment (SIP response /announcement ) Incoming Match CRF Route Plan/ found Treatment Prioritized Request from Tasks ID Target list Client Application CRF Route Plan Successful task Modified Request ( 81 © 2017 Nokia  CRF Provisioning Flow Example for Peering The following diagram shows CRF tables to be provisioned in this training and the relationship between these tables. Note: note all CRF tables are covered in this training CRF Provisioning Sequence in this training: 1. Target List 2. Treatment 3. Digit Analysis 4. Route Plan 5. Route Priority List 6. Route Profile Route Profile Route Priority List 1 Route Priority List No Match Action Target List ID Route Plan Route Priority List 2 Plan Type Route Plan Type Pan ID (Route, Task) (Digit Analysis) …. …. Orig/Term Type Plan Type (Origination, Destination) Digit Analysis Pan ID (Route, Task) Route Plan Data Table Id Digit String Treatment Target List CRF Treatment ID Treatment Type Target Type (IBCF TG Target List) (IBCF Trunk Group) Treatment Virtual Network ID Trunk Group ID Order Priority Weight 82 © 2017 Nokia  > Record Lower order number has higher priority CRFTargetListEntry >> Record 83 © 2017 Nokia Signaling CRF Treatment Table Create CRFTreatment table entries with TREATMENT point to CRF Target List created previously Record > Record >> CRFTreatment 84 © 2017 Nokia  Signaling CRF Digit Analysis Table If the IBCF routing is based on Digit Analysis then one can create CRFDATable entries to select different CRF_TREATMENT_ID (created from previous step) based on different DIGIT_STRING. Note 1: ‘&’ is a wildcard so ‘+1630969&’ will match any digit string that start with +1630969. Note 2: in spreadsheet, one needs to enter ‘+1630969& so EXCEL will not interpret the content as formula Record > Record >> CRFDATable 85 © 2017 Nokia Signaling CRF Route Plan Table One can design the CRF routing to be based on “Digit Analysis”, “Trunk Group”, “Host URI”or “Programmable Routing” (specified in ROUTE_PLAN_TYPE) For “Digit Analysis”. RT_PLAN_DATA_TBL_ID should point to CRDATable. For “Trunk Group”, RT_PLAN_DATA_TBL_ID should point to CRFTrunkGroup For “Host URI”, RT_PLAN_DATA_TBL_ID should point to CRFHostURITable For “Programmable Routing”, RT_PLAN_DATA_TBL_ID should point to CRFProgrammableRouteTable Record >> CRFRoutePlan 86 © 2017 Nokia Signaling CRF Route Priority Table Create CRFRoutePriorityList entry that points to previously created CRFRoutePlan. > Record >> CRFRoutePriorityList 87 © 2017 Nokia Signaling CRF Route Profile Table Create CRFRouteProfile table entry with RT_PRIORITY_LIST_X points to previously create CRFRoutePriorityList Record >> CRFRouteProfile 88 © 2017 Nokia SBC iCCF Data 89 © 2017 Nokia Nokia Internal Use  Signaling LocalCCFConfiguration Table One may need to consider customizing these > case: FQDN primary/secondsary IP/FQDN and >> choice: choice DATASERVERPORT case: IP THREEGPPVERSIONNUMBER >> case: FQDN >> choice: choice2 Specify whether to use 3GPP file naming DATASERVERPORT 1986 or not in THREEGPPRELEASENUMBER 7 THREEGPPVERSIONNUMBER 4 THREEGPPSTANDARDCDRFILENAMING THREEGPPSTANDARDCDRFILENAMING Yes >> LocalCCFConfiguration 90 © 2017 Nokia SBC BGW Data 91 © 2017 Nokia Nokia Internal Use  Media Capacity Profile Parameters Media capacity profile defines the codec to be supported by BGW with resource allocation % for each codec transcoding. The total % must add up to 100%. Capacity Profile Parameters Type Profile Tag G711 G729a Amr2 Amr-wb G722 Opus Evs Capacity Profile Parametersgw.media.capacity.mpu 50 0 25 25 0 0 0 92 © 2017 Nokia  Media IPv4/IPv6 Interface In addition to assigning IPv4/IPv6 to each PIM port, one also needs to assign a previously defined realm name to each PIM port. IPv4 Interface IPv4 Port IPv4 Address Subnet Mask Realm Name SCM OAM 172.39.204.3 255.255.0.0 n/a SCM MGC 172.38.204.1 255.255.0.0 n/a PIM1 Port1 11.31.204.1 255.255.0.0 untrustedRealm1 PIM1 Port2 11.32.204.1 255.255.0.0 trustedRealm1 PIM1 Port3 11.33.204.1 255.255.0.0 untrustedRealm2 PIM1 Port4 11.34.204.1 255.255.0.0 trustedRealm2 93 © 2017 Nokia Other BGW Parameters Once you complete user-input file, you can use YANG Tool to generate full BGW DIF for further customization. For example, the following shows turning on Context Admission Control. h248-profile 94 © 2017 Nokia 95 © Nokia 2017 Confidential