Özel mobil ağ tasarım gereksinimleri

Bu makale, Azure Özel 5G Core (AP5GC) tabanlı özel bir 4G veya 5G ağı tasarlamanıza ve uygulamaya hazırlanmanıza yardımcı olur. Bu ağların nasıl inşa edildiklerine ve ağınızı planladığınızda almanız gereken kararlara ilişkin bir anlayış sağlamayı amaçlar.

Azure Özel MEC ve Azure Özel 5G Core

Azure özel çok erişimli uç işlem (MEC), Microsoft işlem, ağ ve uygulama hizmetlerini kurumsal şirket içinde (uç) bir dağıtımda birleştiren bir çözümdür. Bu uç dağıtımları buluttan merkezi olarak yönetilir. Azure Özel 5G Core, Kurumsal uçta 4G ve 5G çekirdek ağ işlevleri sağlayan Azure Özel Çok Erişimli Edge İşlem (MEC) içinde bir Azure hizmetidir. Kurumsal uç sitesinde cihazlar hücresel radyo erişim ağına (RAN) bağlanır ve Azure Özel 5G Core hizmeti aracılığıyla yukarı akış ağlarına, uygulamalara ve kaynaklara bağlanır. İsteğe bağlı olarak, cihazlar azure özel MEC tarafından sağlanan yerel işlem özelliğini kullanarak veri akışlarını çok düşük gecikme süresiyle işleyerek bunların tümünün kuruluş denetimi altında olmasını sağlar.

Diagram displaying the components of a private network solution. UEs, RANs and sites are at the edge, while Azure region management is in the cloud.

Özel mobil ağ gereksinimleri

Kullanıcı ekipmanının (UE) özel bir hücresel ağa bağlanmasına izin vermek için aşağıdaki özellikler mevcut olmalıdır:

  • UE, radyo erişim ağı (RAN) tarafından kullanılan protokol ve kablosuz spektrum bandı ile uyumlu olmalıdır.
  • UE bir abone kimliği modülü (SIM) içermelidir. SIM, cihazın kimliğini depolayan bir şifreleme öğesidir.
  • Kurumsal sitenin hizmet gerektiren UE'leri içeren tüm bölümlerine hücresel sinyal gönderen ve alan bir RAN olmalıdır.
  • RAN'a ve bir yukarı akış ağına bağlı bir paket çekirdeği örneği olmalıdır. Paket çekirdeği, AĞ üzerinden bağlanıp hizmet isteğinde bulunurken BAE'nin SIM'lerinin kimliğini doğrulamaktan sorumludur. İlkeyi UE'lere ve UE'lerden elde edilen veri akışlarına uygular; örneğin, bir hizmet kalitesi ayarlamak için.
  • IP trafiğini birbirine geçirebilmeleri için, RAN, paket çekirdeği ve yukarı akış ağ altyapısının Ethernet üzerinden bağlanması gerekir.
  • Hizmet yönetimi, telemetri, tanılama ve yükseltmelere izin vermek için paket çekirdeğini barındıran sitenin İnternet'e sürekli, yüksek hızlı bir bağlantısı olmalıdır (en az 100 Mb/sn).

Özel mobil ağ tasarlama

Aşağıdaki bölümlerde, dikkate almanız gereken ağın öğeleri ve ağı dağıtmaya hazırlanırken vermeniz gereken tasarım kararları açıklanmaktadır.

Topoloji

Yerel ağınızı tasarlama ve uygulama, AP5GC dağıtımınızın temel bir parçasıdır. AP5GC paket çekirdeğinizi ve diğer uç iş yüklerini desteklemek için ağ tasarımı kararları almanız gerekir. Bu bölümde, ağınızı tasarlarken dikkate almanız gereken bazı kararlar özetlenmiştir ve bazı örnek ağ topolojileri sağlanır. Aşağıdaki diyagramda temel bir ağ topolojisi gösterilmektedir.

Diagram of a basic network topology.

Tasarımla ilgili dikkat edilecek noktalar

Azure Stack Edge Pro GPU'ya (ASE) dağıtıldığında AP5GC, erişim sinyali ve verileri için fiziksel bağlantı noktası 5'i (5G N2 ve N3 başvuru noktaları/4G S1 ve S1-U başvuru noktaları) ve çekirdek veriler için 6 numaralı bağlantı noktasını (5G N6/4G SGi başvuru noktaları) kullanır. Altıdan fazla veri ağı yapılandırılırsa, çekirdek veriler için 5 numaralı bağlantı noktası da kullanılır.

AP5GC, 5 ve 6 bağlantı noktalarında katman 3 yönlendiricisi olan veya olmayan dağıtımları destekler. Bu, daha küçük kenar sitelerinde ek donanım kullanmaktan kaçınmak için kullanışlıdır.

  • ASE bağlantı noktası 5'i doğrudan RAN düğümlerine (arka arkaya) veya katman 2 anahtarıyla bağlamak mümkündür. Bu topolojiyi kullanırken, eNodeB/gNodeB adresini ASE ağ arabiriminde varsayılan ağ geçidi olarak yapılandırmanız gerekir.
  • Benzer şekilde, ASE bağlantı noktası 6'yı bir katman 2 anahtarıyla çekirdek ağınıza bağlamak mümkündür. Bu topolojiyi kullanırken, alt ağda ASE tarafında ağ geçidi olarak bir uygulama veya rastgele bir adres ayarlamanız gerekir.
  • Alternatif olarak, bu yaklaşımları birleştirebilirsiniz. Örneğin, ASE bağlantı noktası 5'te düz katman 2 ağına sahip ASE bağlantı noktası 6'da bir yönlendirici kullanabilirsiniz. Yerel ağda bir katman 3 yönlendiricisi varsa, bunu ASE'nin yapılandırmasıyla eşleşecek şekilde yapılandırmanız gerekir.

Azure Stack Edge 2'de (ASE 2) dağıtıldığında AP5GC, erişim sinyali ve verileri için fiziksel bağlantı noktası 3'ü (5G N2 ve N3 başvuru noktaları/4G S1 ve S1-U başvuru noktaları) ve çekirdek veriler için 4 numaralı bağlantı noktasını (5G N6/4G SGi başvuru noktaları) kullanır. Altıdan fazla veri ağı yapılandırılırsa çekirdek veriler için 3 numaralı bağlantı noktası da kullanılır.

AP5GC, 3 ve 4 bağlantı noktalarında katman 3 yönlendiricisi olan veya olmayan dağıtımları destekler. Bu, daha küçük kenar sitelerinde ek donanım kullanmaktan kaçınmak için kullanışlıdır.

  • ASE bağlantı noktası 3'e doğrudan (arka arkaya) veya katman 2 anahtarıyla RAN düğümlerine bağlanmak mümkündür. Bu topolojiyi kullanırken, eNodeB/gNodeB adresini ASE ağ arabiriminde varsayılan ağ geçidi olarak yapılandırmanız gerekir.
  • Benzer şekilde, ASE bağlantı noktası 4'i bir katman 2 anahtarıyla çekirdek ağınıza bağlamak mümkündür. Bu topolojiyi kullanırken, alt ağda ASE tarafında ağ geçidi olarak bir uygulama veya rastgele bir adres ayarlamanız gerekir.
  • Alternatif olarak, bu yaklaşımları birleştirebilirsiniz. Örneğin, ASE bağlantı noktası 3'te düz katman 2 ağına sahip ASE bağlantı noktası 4'te bir yönlendirici kullanabilirsiniz. Yerel ağda bir katman 3 yönlendiricisi varsa, bunu ASE'nin yapılandırmasıyla eşleşecek şekilde yapılandırmanız gerekir.

Paket çekirdeğinizde Ağ Adresi Çevirisi (NAT) etkinleştirilmediği sürece, yerel katman 3 ağ cihazının ilgili ekli veri ağı için uygun N6 IP adresi üzerinden UE IP havuzlarına giden statik yollar ile yapılandırılması gerekir.

Örnek ağ topolojileri

Ağınızı AP5GC ile kullanmak üzere ayarlamanın birden çok yolu vardır. Tam kurulum, ihtiyaçlarınıza ve donanımınıza bağlı olarak değişir. Bu bölümde ASE Pro GPU donanımında bazı örnek ağ topolojileri sağlanır.

  • N6 Ağ Adresi Çevirisi (NAT) ile Katman 3 ağı
    Bu ağ topolojisi, ASE'nizin mobil ağ çekirdeğine ve erişim ağ geçitlerine (ase'nizi verilerinize bağlayan ve ağlara erişen yönlendiriciler) bağlantı sağlayan katman 2 cihazına bağlı olmasını sağlar. Bu topoloji en fazla altı veri ağını destekler. Katman 3 yönlendirmeyi basitleştirdiğinden bu çözüm yaygın olarak kullanılır.
    Diagram of a layer 3 network with N6 Network Address Translation (N A T).

  • Ağ Adresi Çevirisi (NAT) olmayan Katman 3 ağı
    Bu ağ topolojisi benzer bir çözümdür, ancak UE IP adresi aralıkları, veri ağı yönlendiricisinde N6 NAT IP adresi sonraki atlama adresi olarak statik yollar olarak yapılandırılmalıdır. Önceki çözümde olduğu gibi, bu topoloji en fazla altı veri ağını destekler. Diagram of a layer 3 network without Network Address Translation (N A T).

  • Düz katman 2 ağ
    Paket çekirdeği, katman 3 yönlendiricileri veya yönlendirici benzeri işlevler gerektirmez. Alternatif bir topoloji, katman 3 ağ geçidi yönlendiricilerinin tamamen kullanılmasını önleyip bunun yerine ASE'nin veri ve erişim ağlarıyla aynı alt ağda yer aldığı bir katman 2 ağı oluşturabilir. Katman 3 yönlendirmesi gerektirmediğinizde bu ağ topolojisi daha ucuz bir alternatif olabilir. Bunun için paket çekirdeğinde Ağ Adresi Bağlantı Noktası Çevirisi'nin (NAPT) etkinleştirilmesi gerekir.
    Diagram of a layer 2 network.

  • Birden çok veri ağı içeren Katman 3 ağı

    • AP5GC, her biri Etki Alanı Adı Sistemi (DNS), UE IP adresi havuzları, N6 IP yapılandırması ve NAT için kendi yapılandırmasına sahip on adede kadar bağlı veri ağını destekleyebilir. Operatör, bir veya daha fazla veri ağında abone olunan UE'leri sağlayabilir ve veri ağına özgü ilke ve hizmet kalitesi (QoS) yapılandırması uygulayabilir.
    • Bu topoloji, N6 arabiriminin her veri ağı için bir alt ağa veya tüm veri ağları için bir alt ağa bölünmesini gerektirir. Bu nedenle bu seçenek, çakışan veri ağı IP aralıklarını veya UE IP aralıklarını önlemek için dikkatli bir planlama ve yapılandırma gerektirir.
      Diagram of layer 3 network topology with multiple data networks.
  • VLAN ve fiziksel erişim/çekirdek ayrımı ile katman 3 ağı

    • Ağınıza katman 3 ağ geçitleri eklemeyi seçseniz de ase trafiğini VLAN'lara ayırabilirsiniz. Trafiği ayrı VLAN'lara ayırmanın daha esnek ağ yönetimi ve artırılmış güvenlik gibi birçok avantajı vardır.
    • Örneğin, yönetim, erişim ve veri trafiği için ayrı VLAN'lar veya ekli her veri ağı için ayrı bir VLAN yapılandırabilirsiniz.
    • VLAN'lar yerel katman 2 veya katman 3 ağ donanımında yapılandırılmalıdır. AsE bağlantı noktası 5 (erişim ağı) ve/veya 6'dan (çekirdek ağ) tek bir bağlantı üzerinde birden çok VLAN taşınacağı için bu bağlantıların her birini VLAN gövdesi olarak yapılandırmanız gerekir. Diagram of layer 3 network topology with V L A N s.
  • 7-10 veri ağlarıyla Katman 3 ağı

    • Altıdan fazla VLAN ile ayrılmış veri ağı dağıtmak istiyorsanız, ek (en fazla dört) veri ağı ASE bağlantı noktası 5'e dağıtılmalıdır. Bu, hem erişim hem de çekirdek trafiği taşıyan bir paylaşılan anahtar veya yönlendirici gerektirir. VLAN etiketleri N2, N3 ve N6 veri ağlarının her birine gerektiği gibi atanabilir.
    • Aynı bağlantı noktasında en fazla altı veri ağı yapılandırılamaz.
    • En iyi performans için, beklenen en yüksek yüke sahip veri ağları bağlantı noktası 6'da yapılandırılmalıdır. Diagram of layer 3 network topology with 10 data networks.

Ağınızı AP5GC ile kullanmak üzere ayarlamanın birden çok yolu vardır. Tam kurulum, ihtiyaçlarınıza ve donanımınıza bağlı olarak değişir. Bu bölümde ASE Pro 2 donanımında bazı örnek ağ topolojileri sağlanmaktadır.

  • N6 Ağ Adresi Çevirisi (NAT) ile Katman 3 ağı
    Bu ağ topolojisi, ASE'nizin mobil ağ çekirdeğine ve erişim ağ geçitlerine (ase'nizi verilerinize bağlayan ve ağlara erişen yönlendiriciler) bağlantı sağlayan katman 2 cihazına bağlı olmasını sağlar. Bu topoloji en fazla altı veri ağını destekler. Katman 3 yönlendirmeyi basitleştirdiğinden bu çözüm yaygın olarak kullanılır.
    Diagram of a layer 3 network with N6 Network Address Translation (N A T).

  • Ağ Adresi Çevirisi (NAT) olmayan Katman 3 ağı
    Bu ağ topolojisi benzer bir çözümdür, ancak UE IP adresi aralıkları, veri ağı yönlendiricisinde N6 NAT IP adresi sonraki atlama adresi olarak statik yollar olarak yapılandırılmalıdır. Önceki çözümde olduğu gibi, bu topoloji en fazla altı veri ağını destekler. Diagram of a layer 3 network without Network Address Translation (N A T).

  • Düz katman 2 ağ
    Paket çekirdeği, katman 3 yönlendiricileri veya yönlendirici benzeri işlevler gerektirmez. Alternatif bir topoloji, katman 3 ağ geçidi yönlendiricilerinin tamamen kullanılmasını önleyip bunun yerine ASE'nin veri ve erişim ağlarıyla aynı alt ağda yer aldığı bir katman 2 ağı oluşturabilir. Katman 3 yönlendirmesi gerektirmediğinizde bu ağ topolojisi daha ucuz bir alternatif olabilir. Bunun için paket çekirdeğinde Ağ Adresi Bağlantı Noktası Çevirisi'nin (NAPT) etkinleştirilmesi gerekir.
    Diagram of a layer 2 network.

  • Birden çok veri ağı içeren Katman 3 ağı

    • AP5GC, her biri Etki Alanı Adı Sistemi (DNS), UE IP adresi havuzları, N6 IP yapılandırması ve NAT için kendi yapılandırmasına sahip on adede kadar bağlı veri ağını destekleyebilir. Operatör, bir veya daha fazla veri ağında abone olunan UE'leri sağlayabilir ve veri ağına özgü ilke ve hizmet kalitesi (QoS) yapılandırması uygulayabilir.
    • Bu topoloji, N6 arabiriminin her veri ağı için bir alt ağa veya tüm veri ağları için bir alt ağa bölünmesini gerektirir. Bu nedenle bu seçenek, çakışan veri ağı IP aralıklarını veya UE IP aralıklarını önlemek için dikkatli bir planlama ve yapılandırma gerektirir.

    Diagram of layer 3 network topology with multiple data networks.

  • VLAN ve fiziksel erişim/çekirdek ayrımı ile katman 3 ağı

    • Ağınıza katman 3 ağ geçitleri eklemeyi seçseniz de ase trafiğini VLAN'lara ayırabilirsiniz. Trafiği ayrı VLAN'lara ayırmanın daha esnek ağ yönetimi ve artırılmış güvenlik gibi birçok avantajı vardır.
    • Örneğin, yönetim, erişim ve veri trafiği için ayrı VLAN'lar veya ekli her veri ağı için ayrı bir VLAN yapılandırabilirsiniz.
    • VLAN'lar yerel katman 2 veya katman 3 ağ donanımında yapılandırılmalıdır. AsE bağlantı noktası 3 (erişim ağı) ve/veya 4'ten (çekirdek ağ) tek bir bağlantı üzerinde birden çok VLAN taşınır, bu nedenle bu bağlantıların her birini bir VLAN gövdesi olarak yapılandırmanız gerekir.

    Diagram of layer 3 network topology with V L A N s.

  • 7-10 veri ağlarıyla Katman 3 ağı

    • Altıdan fazla VLAN ile ayrılmış veri ağı dağıtmak istiyorsanız, ek (en fazla dört) veri ağı ASE bağlantı noktası 3'e dağıtılmalıdır. Bu, hem erişim hem de çekirdek trafiği taşıyan bir paylaşılan anahtar veya yönlendirici gerektirir. VLAN etiketleri N2, N3 ve N6 veri ağlarının her birine gerektiği gibi atanabilir.
    • Aynı bağlantı noktasında en fazla altı veri ağı yapılandırılamaz.
    • En iyi performans için, beklenen en yüksek yüke sahip veri ağları 4 numaralı bağlantı noktasında yapılandırılmalıdır.

    Diagram of layer 3 network topology with 10 data networks.

Alt ağlar ve IP adresleri

Kurumsal sitede özel hücresel ağın tümleştirilmesi gereken mevcut IP ağlarınız olabilir. Bu, örneğin:

  • AP5GC için, çakışma adresleri olmayan mevcut alt ağlarla eşleşen IP alt ağlarını ve IP adreslerini seçme.
  • Yeni ağı IP yönlendiricileri aracılığıyla ayırma veya alt ağlar için özel RFC 1918 adres alanını kullanma.
  • Ağa bağlanırken UE'ler tarafından kullanılmak üzere özel olarak bir IP adresi havuzu atama.
  • Ağ Adresi Bağlantı Noktası Çevirisi 'ni (NAPT) kullanarak, paket çekirdeğinin kendisinde veya sınır yönlendiricisi gibi bir yukarı akış ağ cihazında.
  • Parçalanmayı en aza indiren bir maksimum iletim birimi (MTU) seçerek ağı performans için iyileştirme.

Dağıtım için kullanılacak IPv4 alt ağlarını belgelemelisiniz ve çözümdeki her öğe için kullanılacak IP adreslerini ve eklendiğinde UE'lere ayrılacak IP adreslerini kabul etmeniz gerekir. Trafiğe izin vermek için kurumsal sitede yönlendiricileri ve güvenlik duvarlarını dağıtmanız (veya var olan yönlendiricileri yapılandırmanız) gerekir. Ayrıca napt veya MTU değişikliklerinin ağda nasıl ve nerede gerekli olduğunu da kabul etmeli ve ilişkili yönlendirici/güvenlik duvarı yapılandırmasını planlamalısınız. Daha fazla bilgi için bkz . Özel mobil ağ dağıtmak için önkoşul görevlerini tamamlama.

Ağ erişimi

Tasarımınız, özel 5G ağındaki S_B ve UE'ler tarafından erişilebilen ağlara ve varlıklara ilişkin kuruluş kurallarını yansıtmalıdır. Örneğin, yerel Etki Alanı Adı Sistemi (DNS), Dinamik Ana Bilgisayar Yapılandırma Protokolü (DHCP), İnternet veya Azure'a erişmelerine izin verilse de fabrika işlemleri yerel ağ (LAN) erişimine izin verilmeyebilir. Site ziyaretine gerek kalmadan sorunları giderebilmeniz için ağa uzaktan erişim düzenlemeniz gerekebilir. Ayrıca, kurumsal sitenin yönetim ve/veya kurumsal site dışındaki diğer kaynaklara ve uygulamalara erişim için Azure gibi yukarı akış ağlarına nasıl bağlanacağını da göz önünde bulundurmanız gerekir.

Kurumsal ekiple hangi IP alt ağlarının ve adreslerinin birbiriyle iletişim kurmasına izin verileceğini kabul etmeniz gerekir. Ardından, yerel IP altyapısında bu sözleşmeyi uygulayan bir yönlendirme planı ve/veya erişim denetimi listesi (ACL) yapılandırması oluşturun. Ayrıca, 2. katmandaki öğeleri bölümlemek için sanal yerel ağ (VLAN) kullanabilir ve anahtar dokunuzu belirli VLAN'lara bağlı bağlantı noktaları atamak üzere yapılandırabilirsiniz (örneğin, RAN erişimi için kullanılan Azure Stack Edge bağlantı noktasını Ethernet anahtarına bağlı RAN birimleriyle aynı VLAN'a yerleştirmek için). Ayrıca, destek personelinizin çözümdeki her öğenin yönetim arabirimine uzaktan bağlanmasına olanak tanıyan bir sanal özel ağ (VPN) gibi bir erişim mekanizması ayarlamayı da kuruluşla kabul etmelisiniz. Ayrıca yönetim ve telemetri için Azure Özel 5G Core ile Azure arasında bir IP bağlantısına da ihtiyacınız vardır.

RAN uyumluluğu

Sinyali kurumsal sitede yayınlamak için kullandığınız RAN yerel düzenlemelere uygun olmalıdır. Örneğin, bu şu anlama gelebilir:

  • RAN birimleri homologasyon sürecini tamamlamış ve bir ülkede/bölgede belirli bir frekans bandında kullanımları için mevzuat onayı almıştır.
  • Ran'ın belirli bir konumdaki spektrumu kullanarak yayınlamasına izin aldınız; örneğin, bir telekom operatöründen, düzenleme yetkilisinden veya Spektrum Erişim Sistemi (SAS) gibi teknolojik bir çözümden izin aldınız.
  • Bir sitedeki RAN birimleri, Duyarlık Süresi Protokolü (PTP) ve GPS konum hizmetleri gibi yüksek duyarlıklı zamanlama kaynaklarına erişebilir.

RAN iş ortağınızdan, RAN'ın onaylandığı ülkeler/bölgeler ve sıklık bantları istemeniz gerekir. Çözümünüzü sağladığınız ülkeleri ve bölgeleri kapsayacak şekilde birden çok RAN iş ortağı kullanmanız gerektiğini fark edebilirsiniz. RAN, UE ve paket çekirdeğinin tümü standart protokolleri kullanarak iletişim kursa da, kurumsal müşterideki herhangi bir dağıtımdan önce Azure Özel 5G Core, UE'ler ve RAN arasında belirli 4G Uzun Süreli Evrim (LTE) veya 5G tek başına (SA) protokolü için birlikte çalışabilirlik testi gerçekleştirmenizi öneririz.

RAN'niz, kullanmak üzere yapılandırıldığı frekans bandındaki tüm UE'lere bir Genel Arazi Mobil Ağ Kimliği (PLMN Kimliği) iletir. PLMN kimliğini tanımlamanız ve spektruma erişiminizi onaylamanız gerekir. Bazı ülkelerde/bölgelerde, spektrum ulusal/bölgesel düzenleyiciden veya yerleşik telekomünikasyon operatöründen alınmalıdır. Örneğin, band 48 Citizens Broadband Radio Service (CBRS) spektrumunu kullanıyorsanız, RAN'ın sürekli yayın yetkisine sahip olup olmadığını denetleyebilmesi için kurumsal sitede bir Spektrum Erişim Sistemi (SAS) etki alanı proxy'si dağıtmak için RAN iş ortağınızla birlikte çalışmanız gerekebilir.

Maksimum İletim Birimleri (MTU)

Maksimum İletim Birimi (MTU), bir IP bağlantısının özelliğidir ve bağlantının her ucundaki arabirimlerde yapılandırılır. Bir arabirimin yapılandırılmış MTU'sünü aşan paketler, göndermeden önce IPv4 parçalanması yoluyla daha küçük paketlere bölünür ve hedeflerinde yeniden birleştirilir. Ancak, bir arabirimin yapılandırılmış MTU'sunun bağlantının desteklenen MTU'sunun üstünde olması durumunda paket doğru şekilde aktarılamaz.

IPv4 parçalanmasından kaynaklanan iletim sorunlarını önlemek için, 4G veya 5G paket çekirdeği UE'lere hangi MTU'ları kullanmaları gerektiğini belirtir. Ancak UE'ler her zaman paket çekirdeği tarafından işaretlenen MTU'ya saygı duymaz.

UE'lerden gelen IP paketleri, kapsüllemeden ek yük ekleyen RAN'dan tünellenir. Bu nedenle, iletim sorunlarını önlemek için UE için MTU değeri, S_SAYI ve paket çekirdeği arasında kullanılan MTU değerinden daha küçük olmalıdır.

RAN'ler genellikle 1500 MTU ile önceden yapılandırılmış olarak gelir. Paket çekirdeğinin varsayılan UE MTU değeri, kapsülleme ek yüküne izin vermek için 1440 bayttır. Bu değerler, RAN birlikte çalışabilirliğini en üst düzeye çıkarır, ancak bazı UE'lerin varsayılan MTU'ları gözlemlemeyeceği ve IPv4 parçalanması gerektiren ve ağ tarafından bırakılan daha büyük paketler oluşturma riski vardır. Bu sorundan etkileniyorsanız, 1560 veya üzeri bir MTU kullanacak şekilde RAN'ı yapılandırmanız kesinlikle önerilir; bu da kapsülleme için yeterli ek yük sağlar ve standart 1500 MTU kullanarak bir UE ile parçalanmayı önler.

Paket çekirdeği tarafından işaretlenen UE MTU'sunu da değiştirebilirsiniz. MTU'nuzu UE'leriniz tarafından desteklenen aralıktaki bir değere ve S_SAYI_ÜRET'in işaret ettiği MTU'nın 60 bayt altına ayarlamanızı öneririz. Şunlara dikkat edin:

  • Veri ağı (N6), UE MTU ile eşleşecek şekilde otomatik olarak güncelleştirilir.
  • Erişim ağı (N3), UE MTU artı 60 ile eşleşecek şekilde otomatik olarak güncelleştirilir.
  • 1280 ile 1930 bayt arasında bir değer yapılandırabilirsiniz.

Paket çekirdeği tarafından işaretlenen UE MTU'sunu değiştirmek için bkz . Paket çekirdeği örneğini değiştirme.

Sinyal kapsamı

UE'ler, sitedeki herhangi bir konumdan RAN ile iletişim kurabilmelidir. Başka bir deyişle sinyallerin, sitede hareket eden UE'leri (örneğin, iç ve dış alanlar arasında) desteklemek için engelleri ve ekipmanları esnetme dahil olmak üzere ortamda etkili bir şekilde yayılması gerekir.

Kapsamın yeterli olduğundan emin olmak için RAN iş ortağınızla ve kuruluşla bir site anketi gerçekleştirmeniz gerekir. FARKLı ortamlardaki RAN birimlerinin özelliklerini ve tüm sınırları (örneğin, tek bir birimin destekleyebilecek ekli UE sayısı) anladığınızdan emin olun. UE'leriniz sitede hareket edecekse, S_ÜRET'in X2 (4G) veya Xn (5G) devretmeyi desteklediğini ve bu sayede UE'nin iki RAN birimi tarafından sağlanan kapsam arasında sorunsuz geçiş yapmasını sağladığını da onaylamanız gerekir. RAN, X2 (4G) veya Xn (5G) desteklemiyorsa, S1 (4G) ve UE mobility için N2 (5G) desteklenmelidir. UE'lerin özel bir kurumsal ağ ile bir telekomünikasyon operatörü tarafından sunulan genel hücresel ağ arasında gezinmek için bu devretme tekniklerini kullanamayacağını unutmayın.

Sims

Her UE, abone kimliği modülünde (SIM) kodlanmış bir kimlik sunmalıdır. SIM'ler farklı fiziksel biçim faktörlerinde ve yalnızca yazılım biçiminde (eSIM) kullanılabilir. SIM'de kodlanan veriler, Azure Özel 5G Core'daki RAN ve sağlanan kimlik verilerinin yapılandırmasıyla eşleşmelidir.

UE'lerle uyumlu ve dağıtım için kullanmak istediğiniz PLMN kimliği ve anahtarlarla programlanmış faktörlerdeki SIM'leri alın. Fiziksel SIM'ler, nispeten düşük maliyetle açık pazarda yaygın olarak mevcuttur. ESIM'leri kullanmayı tercih ediyorsanız, UE'lerin hücresel ağa bağlanmadan önce kendilerini yapılandırabilmeleri için gerekli eSIM yapılandırmasını ve sağlama altyapısını dağıtmanız gerekir. Azure Özel 5G Core'da eşleşen girişleri sağlamak için SIM iş ortağınızdan aldığınız sağlama verilerini kullanabilirsiniz. SIM verilerinin güvenli tutulması gerektiğinden, SIM'leri sağlamak için kullanılan şifreleme anahtarları ayarlandıktan sonra okunamaz, bu nedenle Azure Özel 5G Core'da verileri yeniden sağlamanız gerektiğinde bunları nasıl depoladığınıza dikkat etmeniz gerekir.

Otomasyon ve tümleştirme

Otomasyon ve diğer programlama tekniklerini kullanarak kurumsal ağlar oluşturmak zaman kazandırır, hataları azaltır ve daha iyi sonuçlar üretir. Bu teknikler, ağın yeniden oluşturulmasını gerektiren bir site hatası durumunda da bir kurtarma yolu sağlar.

Dağıtımlarınıza kod olarak programlı bir altyapı yaklaşımı benimsemenizi öneririz. Parametreleri projenin tasarım aşamasında topladığınız değerlerle giriş olarak kullanarak dağıtımınızı oluşturmak için şablonları veya Azure REST API'sini kullanabilirsiniz. SIM verileri, anahtar/yönlendirici yapılandırması ve ağ ilkeleri gibi sağlama bilgilerini makine tarafından okunabilir biçimde kaydetmeniz gerekir, böylece bir hata durumunda yapılandırmayı ilk yaptığınız gibi yeniden uygulamaya alabilirsiniz. Hatadan kurtarmanın bir diğer en iyi yöntemi, ilk ünite başarısız olursa kurtarma süresini en aza indirmek için yedek bir Azure Stack Edge sunucusu dağıtmaktır; Ardından, dağıtımı hızlı bir şekilde yeniden oluşturmak için kaydedilmiş şablonlarınızı ve girişlerinizi kullanabilirsiniz. Şablonları kullanarak ağ dağıtma hakkında daha fazla bilgi için bkz. Hızlı Başlangıç: Özel mobil ağ ve site dağıtma - ARM şablonu.

Ayrıca diğer Azure ürünlerini ve hizmetlerini özel kurumsal ağ ile nasıl tümleştirdiğiniz de göz önünde bulundurulmalıdır. Bu ürünler Arasında Microsoft Entra Kimliği ve rol tabanlı erişim denetimi (RBAC) bulunur. Burada kiracıların, aboneliklerin ve kaynak izinlerinin sizinle kuruluş arasında var olan iş modeliyle nasıl uyumlu olacağını ve müşteri sistemi yönetimine kendi yaklaşımınız olarak nasıl uyumlu olacağını göz önünde bulundurmanız gerekir. Örneğin, kuruluşunuz için en uygun abonelikleri ve kaynak grubu modelini ayarlamak için Azure Blueprints'i kullanabilirsiniz.

Sonraki adımlar