Gå til innhold

TEST: Huawei Nova Plus


Anbefalte innlegg

Videoannonse
Annonse

 

 

  • Bluetooth:
      • 4.1
  • Wi-Fi:
      • 802.11 b, g, n

 

Det tviholdes fremdeles på Bluetooth 4.1 når det allerede finnes 4.2 i markedet.

Det tviholdes fremdeles med toppfart "n" når det svært lenge faktisk har funnes bedre til WiFi.

 

Kan noen forklare meg hvorfor enkelte sprellferske nyheter som presenteres av året (2016) holdes slik igjen på denne utviklingen. Skyldes det at de fremdeles presser inn eldre CPU'er med telefonene, eller andre forhold?

Lenke til kommentar

 

 

 

  • Bluetooth:
  • 4.1
[*]Wi-Fi:
  • 802.11 b, g, n

 

Det tviholdes fremdeles på Bluetooth 4.1 når det allerede finnes 4.2 i markedet.

Det tviholdes fremdeles med toppfart "n" når det svært lenge faktisk har funnes bedre til WiFi.

 

Kan noen forklare meg hvorfor enkelte sprellferske nyheter som presenteres av året (2016) holdes slik igjen på denne utviklingen. Skyldes det at de fremdeles presser inn eldre CPU'er med telefonene, eller andre forhold?

Kanskje fordi brukere flest ikke vet forskjellen, og heller ikke vil merke så mye til forskjellen. Enormt mange brukere har ikke 802.11ac nett hjemme, og det er masse arbeidsplasser og hotspots som heller ikke kjører ac. Det finnes faktisk de som ikke er over på n enda. 802.11n vil da være tilstrekkelig for de fleste.

Lenke til kommentar

Bluetooth versjon 4.2 har en rekke fordeler over tidligere versjoner ihvertfall. Så der kan det faktisk hende at brukeren før eller siden vil merke en slags forskjell på den ene eller andre måten.
 
https://www.quora.com/What-are-the-main-differences-between-Bluetooth-4-0-4-1-and-4-2-in-the-Layers-Baseband-LMP-L2CAP-app-Layer
 
videre:
 
https://www.google.no/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=bluetooth+version+4.2
 
 
 


 
Bluetooth 4.2 introduces several new features that improve speed and privacy over Bluetooth 4.1 but the main advantage is allowing chips to use Bluetooth over Internet Protocol version 6 (IPv6) for direct Internet access. With this, the possibilities expand beyond thoseof current designs and markets to include any type of Bluetooth device requiring speed and security in the IoT.
 
Why use BLE 4.2 instead of BLE 4.1? The Bluetooth SIG recommends implementing Bluetooth 4.2 in all new designs and requires the same qualification process as all other Bluetooth designs. Devices using Bluetooth Smart will be backward compatible with Bluetooth 4.0 or 4.1 devices that also implement the low energy features. Devices implementing the (BR/EDR) Core Configuration will be backward compatible to all adopted Bluetooth Core versions beginning with 1.1 that also implement Bluetooth BR/EDR.

IoT Capabilities:

  • Low-power IP (IPv6/6LoWPAN)
  • Bluetooth Smart Internet Gateways (GATT)

With BLE 4.2 Bluetooth Smart sensors can transmit data over the internet.
 
Security:

  • LE Privacy 1.2
  • LE Secure Connections

With new, more power efficient and highly secure features, BLE 4.2 provides additional benefits allowing only trusted owners to track device location and confidently pair devices.
 
Speed:

  • 250% Faster
  • 10x More Capacity

Compared to previous versions, BLE 4.2 enables 250% faster and more reliable over-the-air data transmission and 10x more packet capacity.
LAYERS

 
Channel Manager
The channel manager is responsible for creating, managing, and destroying L2CAP channels for the transport of service protocols and application data streams. The channel manager uses the L2CAP protocol to interact with a channel manager on a remote (peer) device to create these L2CAP channels and connect their endpoints to the appropriate entities. The channel manager interacts with its local link manager to create new logical links (if necessary) and to configure these links to provide the required QoS for the type of transported data.
L2CAP Resource Manager
The L2CAP resource manager block is responsible for managing the ordering of submission of PDU fragments to the baseband and some relative scheduling between channels to ensure L2CAP channels with QoS commitments are not denied access to the physical channel due to Bluetooth controller resource exhaustion. This is required because the architectural model does not assume that the Bluetooth controller has limitless buffering, or that the HCI is a pipe of infinite bandwidth.
L2CAP resource managers may also carry out traffic conformance policing to ensure that applications are submitting L2CAP SDUs within the bounds of their negotiated QoS settings. The general Bluetooth data transport model assumes well-behaved applications, and does not define how an implementation is expected to deal with this problem.
Device Manager
The device manager is the functional block in the baseband that controls the general behavior of the Bluetooth enabled device. It is responsible for all operation of the Bluetooth system not directly related to data transport, such as inquiring for the presence of other nearby Bluetooth enabled devices, connecting to other Bluetooth enabled devices or making the local Bluetooth enabled device discoverable or connectable by other devices.
The device manager requests access to the transport medium from the baseband resource controller in order to carry out its functions.
The device manager also controls local device behavior implied by a number of the HCI commands, such as managing the device local name, any stored link keys, and other functionality.
Link Manager
The link manager is responsible for the creation, modification, and release of logical links (and, if required, their associated logical transports), as well as the update of parameters related to physical links between devices. The link manager achieves this by communicating with the link manager in remote Bluetooth devices using the link management protocol (LMP).
The LMP allows the creation of new logical links and logical transports between devices when required, as well as the general control of link and transport attributes such as the enabling of encryption on the logical transport, the adapting of transmit power on the physical link or the adjustment of QoS settings for a logical link.
Baseband Resource Manager
The baseband resource manager is responsible for all access to the radio medium. It has two main functions. At its heart is a scheduler that grants time on the physical channels to all of the entities that have negotiated an access contract. The other main function is to negotiate access contracts with these entities. An access contract is effectively a commitment to deliver a certain QoS that is required in order to provide a user application with an expected performance.
The access contract and scheduling function must take account of any behavior that requires use of the Bluetooth radio. This includes, for example, the normal exchange of data between connected devices over logical links and logical transports, as well as the use of the radio medium to carry out inquiries, make connections, be discoverable or connectable, or to take readings from unused carriers during the use of AFH mode.
In some cases, the scheduling of a logical link results in changing to a different physical channel from the one that was previously used. This may be, for example, due to involvement in scatternet, a periodic inquiry function, or page scanning. When the physical channels are not time slot aligned, then the resource manager also accounts for the realignment time between slots on the original physical channel and slots on the new physical channel. In some cases, the slots naturally align due to the same device clock used as a reference for both physical channels.
Link Controller
The link controller is responsible for the encoding and decoding of Bluetooth packets from the data payload and parameters related to the physical channel, logical transport and logical link.
The link controller carries out the link control protocol signaling (in close conjunction with the scheduling function of the resource manager), which is used to communicate flow control and acknowledgement and retransmission request signals. The interpretation of these signals is a characteristic of the logical transport associated with the baseband packet. Interpretation and control of the link control signaling is normally associated with the resource manager's scheduler.
RF
The RF block is responsible for transmitting and receiving packets of information on the physical channel. A control path between the baseband and the RF block allows the baseband block to control the timing and frequency carrier of the RF block. The RF block transforms a stream of data to and from the physical channel and the baseband into required formats.

 

Endret av G
Lenke til kommentar
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...