Mobile Networks Support [Документация VAS Experts]
Документация VAS Experts Документация VAS Experts-mobile
in

Settings

  • Show page
  • Old revisions
  • Export to PDF
  • Backlinks
  • Show page
  • Old revisions
  • Export to PDF
  • Backlinks

    • Differences

    This shows you the differences between two versions of the page.

    Link to this comparison view

    Both sides previous revisionPrevious revision
    Next revision    		Previous revision
    en:dpi:dpi_components:platform:dpi_mobile_spec:start [2023/10/10 08:25] – external edit 127.0.0.1en:dpi:dpi_components:platform:dpi_mobile_spec:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
    Line 1: Line 1:
    -====== Mobile Networks Support ====== 
    -{{indexmenu_n>11}} 
      
    -Stingray SG can detect GTP-C traffic and extract subscriber parameters for the subscriber's IP and login binding from the GTP session creation requests. GTP-C versions 1 and 2 are supported. 
    -GTP support is enabled by parameters in fastdpi.conf: 
    -<code> 
    -    # bras_enable=1 
    -    # 
    -    # GTP processing mode 
    -    # Values: 
    -    #   0 - (default) GTP processing is disabled 
    -    #   1 - [bind mode] In this mode, BNG/BRAS processes GTP-C packets of the session start and end, 
    -    #       binding the IP-address issued to the subscriber with the login (IMSI or MSISDN is used as the login). 
    -    #       At the end of the session, the login-IP connection is broken. 
    -    #   2 - [auth mode] authorization of GTP sessions is enabled. In this mode, BNG/BRAS processes GTP-C session start and end packets.  
    -    #       Upon successful start of the GTP session, BRAS sends an L3 authorization request to PCRF,  
    -    #       transmitting the subscriber's IP address, IMSI, MSISDN, IMEI and other parameters. 
    -    #       At the end of the session, the login-IP connection is broken. 
    -    #       SSG does not terminate GTP sessions, all GTP-C packets are dropped. 
    -    #   3 - [passive bind mode] Similar to mode 1 [mirror bind mode], but GTP-C packets are not dropped. 
    -    #       The SSG should be in a gap on the S11 or S5 interface. 
    -    #   4 - [passive auth mode] Similar to mode 2 [mirror auth mode], but GTP-C packets are not dropped. 
    -    #       The SSG should be in a gap on the S11 or S5 interface. 
    -#bras_gtp_mode=0 
    -</code> 
    - 
    - 
    -Creating a session (bind IP-LOGIN) on responses: 
    -<code> 
    -    #Response to Create PDP Context Request for GTPv1: 
    -Create PDP Context Response 
    - 
    -    #Response to Create Session Request for GTPv2:  
    -Create Session Response 
    -</code> 
    - 
    -Deleting a session (bind IP-LOGIN) on responses: 
    -<code> 
    -    #Response to Delete PDP Context Request for GTPv1:   
    -Delete PDP Context Response 
    - 
    -    #Response to Delete Session Request for GTPv2:  
    -Delete Session Response 
    - 
    -    #Response to Delete Bearer Request for GTPv2:  
    -Delete Bearer Response  
    -</code> 
    - 
    - 
    -The Stingray SG connection point is set by the parameter: 
    -<code> 
    -     # Where the SSG is connected (which GTP-C is fed to the SCAT) 
    -     # Valid values: 
    -     # 0 - S5 protocol (SGW <-> PGW). This is the default 
    -     # 1 - S11 protocol (MME <-> SGW) 
    -bras_gtp_mountpoint=0 
    -</code> 
    - 
    -In mirror mode (''bras_gtp_mode'' 1 or 2), SSG drops all incoming GTP-C packets. 
    -In passive mode ( ''bras_gtp_mode'' 3 or 4) SSG passes GTP-C traffic through itself. 
    - 
    -You should also set the maximum size of active GTP-sessions internal database in fastdpi.conf 
    - 
    -<code> 
    -    # Max number of concurrent GTP-sessions 
    -    # We recommend setting this parameter 1.5-2 times more than the actual max number of sessions 
    -    # Default value: 10000 sessions, minimum value: 10000 
    -#bras_gtp_session=10000 
    -</code> 
    - 
    -After receiving a request to create a GTP-C session, SSG waits for a packet of successful session creation. Only at this moment, upon receiving a successful response and issuing an IP address to the subscriber, connects the login and IP. The response timeout is set by a parameter in fastdpi.conf: 
    -<code> 
    -    # Max time to wait for a response to a GTP session creation, seconds 
    -    # Default = 3 seconds 
    -#bras_gtp_pending_timeout=3 
    -</code> 
    - 
    -IMSI or MSISDN can be used as a login, which is set by a parameter in fastdpi.conf: 
    -<code> 
    -    # What is the subscriber's login for GTP: 
    -    # 0 - IMSI (by default) 
    -    # 1 - MSISDN 
    -#bras_gtp_login=0 
    -</code> 
    - 
    -<note important>Using MSISDN (phone number) as a login, although more familiar to everyone, is not safe: MSISDN may not be present in GTP-C session creation packets. In this case, SSG will use IMSI as a login. As a result, it will not be clear what the login is - MSISDN or IMSI. Therefore, we recommend using only IMSI as a login </note> 
    - 
    -To detect GTP-U, you have to enable tunnel parsing: 
    -<code> 
    -   # enable the tunnels parsing by dispatchers 
    -check_tunnels=1 
    -   # enable the detection and parsing of GTP-U 
    -detect_gtp_tunnel=1 
    -</code> 
    -When you enable parsing of GTP-U tunnels, SSG will work with the real IP-address of the subscriber, and not with the IP-address of the tunnel. That means that it becomes possible to apply filtering, services and policing to the GTP-subscriber. 
    - 
    -SSG does not terminate GTP-U tunnels. 
    - 
    -The internal database of GTP-sessions can be controlled with a special set of [[en:dpi:bras_bng:cli:gtp|CLI-commands]].